On 2013-06-28 08:41:46 -0400, Robert Haas wrote: > On Fri, Jun 28, 2013 at 3:32 AM, Andres Freund <and...@2ndquadrant.com> wrote: > > What that means is that for every heap record in the target database in > > the WAL we need to query pg_class to turn the relfilenode into a > > pg_class.oid. So, we can easily replace syscache.c with some custom > > caching code, but I don't think it's realistic to get rid of that > > index. Otherwise we need to cache the entire pg_class in memory which > > doesn't sound enticing. > > The alternative I previously proposed was to make the WAL records > carry the relation OID. There are a few problems with that: one is > that it's a waste of space when logical replication is turned off, and > it might not be easy to only do it when logical replication is on. > Also, even when logic replication is turned on, things that make WAL > bigger aren't wonderful. On the other hand, it does avoid the > overhead of another index on pg_class.
I personally favor making catalog modifications a bit more more expensive instead of increasing the WAL volume during routine operations. I don't think index maintenance itself comes close to the biggest cost for DDL we have atm. It also increases the modifications needed to imporantant heap_* functions which doesn't make me happy. How do others see this tradeoff? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
