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