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

Reply via email to