Re: changeset generation v5-01 - Patches & git tree
От | Andres Freund |
---|---|
Тема | Re: changeset generation v5-01 - Patches & git tree |
Дата | |
Msg-id | 20130628124655.GC11757@alap2.anarazel.de обсуждение исходный текст |
Ответ на | Re: changeset generation v5-01 - Patches & git tree (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: changeset generation v5-01 - Patches & git tree
Re: changeset generation v5-01 - Patches & git tree |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: