Re: updated SORT/LIMIT patch

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> Hum. The major change I see is the bit related to rescans where you made it
> resort if the bound had changed. But surely the only way the bound can change
> is if it's a parameter, and if there is a parameter then surely the executor
> must be doing more than just a plain rescan?

The problem is that a parameter change in the LIMIT's expression would
not normally be propagated below the LIMIT. In this case, since we're
allowing its effects to bubble down one more level of the tree, we need
to make sure that that level is recomputed too.

> What does the executor do differently in the case of a subplan with a
> parameter that makes it re-execute the plan from scratch and not just do a
> simple rescan?

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.

regards, tom lane