On 2013-06-28 08:41:46 -0400, Robert Haas wrote:
> On Fri, Jun 28, 2013 at 3:32 AM, Andres Freund <andres@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