Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> 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
