"Mason Hale" <masonhale at gmail.com> writes:
> Hello everyone --
>
> I'm planning to use Slony divide work across two postgres servers.
>
> Our environment is such that there are two mostly separate pieces,
> each updated by a separate application. The data that is updated by
> the first application is only read by the second application and data
> updated by the second application is only read by the first
> application.
>
> Slony looks like a good solution to our needs, as we can replicate one
> set of tables in each direction between a first and second database
> server.
>
> We're running 8.2.4 and our db is ~150GB in size (and growing fast).
>
> We are using the table partitioning features of Postgres to break up
> our larger tables and keep indexes in RAM.
>
> My questions are:
>
> - In slony, when replicating inherited/partitioned tables, do you
> replicate each child table individually? Or can you add the slony
> triggers to the parent table? (Because some of these tables are
> partitioned based on a creation date, we end up adding new tables
> frequently).

You replicate each child table individually.

Note that there is an example in the tests under
slony1-engine/tests/testinherit.

> - Is it possible to replicate from a partitioned table to a
> non-partitioned table?

At present there is no ability to rename what table data goes into, so
I think the practical answer to that is "no."

Note that Slony-I isn't really aware of partitioning; it's just aware
of what tables you ask it to replicate.

> - Is it possible to replicate from a partitioned table to table that
> is partitioned differently?

Perhaps, but...

As mentioned above, Slony-I isn't really aware of partitioning, so you
could have a different partitioning scheme from origin to subscriber.
But Slony-I would copy data around based on the partitioning scheme on
the origin.  Data would not shift around based on the subscriber's
configuration.

> So would it be possible to create a table in the first database
> partitioned by serial primary key, and replicate that table (and its
> child tables) to a second database where the same table is partitioned
> based on creation date?

I don't think so, at this point in time.  Not beyond possibility; some
(not yet documented) log shipping work is oriented to something
somewhat like this...
-- 
"cbbrowne","@","acm.org"
http://linuxdatabases.info/info/advocacy.html
"When a float occurs  on the same page  as the start of a supertabular
you can expect unexpected results." -- Documentation of supertabular.sty