Boszormenyi Zoltan wrote: > c. splitting wal into different replication sets
Just a side note: in addition to its use for partial replication, this might have potential for performance-prioritizing databases or tablespaces. Being able to separate WAL logging so that different DBs, tablespaces, etc went to different sets of WAL logs would allow a DBA to give some databases or tablespaces dedicated WAL logging space on faster storage. If partial recovery is implemented, it might also permit less important databases to be logged to fast-but-unsafe storage such as a non-BBU disk controller with write cache enabled, without putting more important databases in the same cluster in danger. More importantly, if the WAL writing was done in different wal writer backends, the admin could also use nice and ionice to encourage the OS to favour WAL logging for some DBs over others. Currently all these things require splitting the install into multiple clusters, incurring config management and backup overhead and most importantly partitioning shared memory. OTOH, even with split WAL logging, you still have the shared bgwriter to contend with, and the effects of an unimportant query pushing data related to more performance-critical DBs out of shm or OS cache. So perhaps splitting the cluster is actually the best answer, and a complete implementation of DB prioritization would land up looking a lot like multiple Pg clusters multiplexed on one port anyway... In any case, I thought it worth mentioning as something that may be worth keeping in mind - or considering and disregarding - while looking at the WAL changes involved in partial replication. -- Craig Ringer -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
