| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: changeset generation v5-01 - Patches & git tree |
| Date: | 2013-06-28 12:41:46 |
| Message-ID: | CA+TgmobBieanEfGwVYryqxMUUUNmT8wrioq+LZ_rzh5iQebaZw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jun 28, 2013 at 3:32 AM, Andres Freund <andres(at)2ndquadrant(dot)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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2013-06-28 12:46:55 | Re: changeset generation v5-01 - Patches & git tree |
| Previous Message | Atri Sharma | 2013-06-28 10:04:12 | Re: Group Commits Vs WAL Writes |