Typically, when I give talks about PostgreSQL, Stado or Postgres-XC, I like to use examples as much as possible to get my points across to the audience. This usually presents a problem in deciding what data to use in the examples. The old stand-by is to use pgbench to generate a bunch of sample data, but the values are meaningless to the audience, and you're a bit limited with what you can show. I've also used the sample databases from PG Foundry but also found them lacking.
 

Reading through Google's Spanner paper, I can't help but see the parallels to Postgres-XC. Although the two solutions tackle different problem sets, the fact that they are both distributed databases with the goal of providing consistency out to the client, results in very similar architectures. Take for example the first paragraph in the abstract of the paper. If you change just a few words, it does a great job of describing what Postgres-XC can do:

Since first adding PostGIS support to Stado last year, I've heard from a number of people needing to scale their write workload in addition to reads. The architecture of Stado doesn't really lend itself to a write intensive application, but luckily Postgres-XC does. Write intensive PostGIS applications have a few interesting challenges that many applications don't experience. First is just the size of a typical row. A geometry column typically contains a lot of rich information, but that adds up to move size on disk.