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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
