Re: logical changeset generation v4

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: logical changeset generation v4
Date: 2013-01-21 07:25:56
Message-ID: 20130121072556.GA6880@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2013-01-20 21:45:11 -0500, Robert Haas wrote:
> On Fri, Jan 18, 2013 at 12:32 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> > Makes sense?
>
> Yes. The catalog timetravel stuff still gives me heartburn. The idea
> of treating system catalogs in a special way has never sat well with
> me and still doesn't - not that I am sure what I'd like better. The
> complexity of the whole system is also somewhat daunting.

Understandable :(

Althoutg it seems to me most parts of it have already been someplace
else in the pg code, and the actual timetravel code is relatively small.

> But my question with relation to this specific patch was mostly
> whether setting the table OID everywhere was worth worrying about from
> a performance standpoint, or whether any of the other adjustments this
> patch makes could have negative consequences there, since the
> Satisfies functions can get very hot on some workloads. It seems like
> the consensus is "no, that's not worth worrying about", at least as
> far as the table OIDs are concerned.

I agree, I don't really see any such potential of that here, the
effectively changed amount of code is very minor since the interface
mostly stayed the same due to the HeapTupleSatisfiesVisibility wrapper.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-01-21 07:28:56 Re: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
Previous Message Pavan Deolasee 2013-01-21 07:19:06 Re: Removing PD_ALL_VISIBLE