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
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 |