From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | "pgsql-patches" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: updated SORT/LIMIT patch |
Date: | 2007-05-17 19:42:28 |
Message-ID: | 12213.1179430948@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
I wrote:
> I am thinking that a cleaner fix is probably to make ExecRescanLimit do
> the recompute_limits() bit immediately, so that the new limits are
> available to the Sort node when it gets the rescan call. The comment
> about timing of recompute_limits() is referring to the fact that
> parameters aren't set at ExecInitLimit() time, but I believe they are
> (and should be) available at Rescan time. Will give it a try anyway.
Indeed, this way seems to work fine --- and in fact that's what we'd
have to do anyway if we were to merge the parameter-passing into
chgParam signaling. I didn't try to do that, just committed a patch
to fix the immediate problem.
BTW, as for your earlier worries about useless re-sorts when
randomAccess wasn't requested: the design intention is that randomAccess
*will* be requested in any situation where repeat scans are likely. So
there's no point in uglifying the tuplesort API to make an unexpected
rescan fast. If you are seeing cases where a useless re-sort actually
happens, we might have some bugs in the EXEC_FLAG_REWIND signaling.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-05-17 19:48:47 | Re: UTF8MatchText |
Previous Message | Bruce Momjian | 2007-05-17 19:11:29 | Re: Diagnostic functions |