From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Mark Cave-Ayland <mark(dot)cave-ayland(at)siriusit(dot)co(dot)uk>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP patch: reducing overhead for repeat de-TOASTing |
Date: | 2008-07-02 16:52:47 |
Message-ID: | 13038.1215017567@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> It would be simple enough to fix nodeSubplan.c to copy the data into
>> an upper-level Slot rather than a bare tuple. But this makes me wonder
>> how many other places are like this. In the past there wasn't that much
>> benefit to pulling data from a Slot instead of a bare tuple, so I'm
>> afraid we might have a number of similar gotchas we'd have to track
>> down.
> I compare this to adding CHECK_FOR_INTERRUPTS(): let's declare that
> every usage of bare tuples is a not-very-serious bug, and we can fix
> them one by one as we come across them.
Unfortunately we can't usefully have such a rule --- consider sorting
for example. We're not going to change over to using TupleTableSlots
as the items being sorted. What I foresee if we go down this path
is that there will be some places where we can fix toasting performance
problems by inserting a Slot, and some where we can't.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-07-02 16:55:42 | Re: [WIP] patch - Collation at database level |
Previous Message | Magnus Hagander | 2008-07-02 16:46:31 | Re: [GENERAL] pg crashing |