Gregory Stark <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> writes: >> Look at the chgParam signaling. Since a Sort node itself has no >> parameters, it historically has only had to re-sort if its input node >> suffers a parameter change, which it checks in ExecReScanSort. But now >> the bound effectively acts like a parameter, and has to force a >> recomputation.
> Hm, that all makes sense now. But then there's something mysterious going on > still as the regression test I tried to write for this actually does work: Yeah, because in this example nodeSort doesn't ask for randomAccess to the sort result, and so ExecReScanSort is forced to repeat the sort anyway. [ greps a bit... ] It looks like the only way that you could expose the bug in the current state of the system would be if the sort/limit with the outer parameter were the inside of a nestloop join in the subplan. nodeNestloop would set EXEC_FLAG_REWIND, causing nodeSort to set randomAccess, allowing ExecReScanSort to suppose that it could rewind the sort. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly