On 2020-Mar-23, James Coleman wrote: > 4. nodeIncrementalSort.c ExecReScanIncrementalSort: This whole chunk > is suspect. I've mentioned previously I don't have a great mental > model of how rescan works and its invariants (IIRC someone said it was > about moving around a result set in a cursor). Regardless I'm pretty > sure this code just doesn't work correctly.
I don't think that's the whole of it. My own vague understanding of ReScan is that it's there to support running a node again, possibly with different parameters. For example if you have a join of an indexscan on the outer side and an incremental sort on the inner side, and the values from the index are used as parameters to the incremental sort, then the incremental sort is going to receive ReScan calls for each of the values that the index returns. Sometimes the index could give you the same values as before (because there's a dupe in the index), so you can just return the same values from the incremental sort; but other times it's going to return different values so you need to reset the incremental sort to "start from scratch" using the new values as parameters. Now, if you have a cursor reading from the incremental sort and fetch all tuples, then rewind completely and fetch all again, then that's going to be a rescan as well. I agree with you that the code doesn't seem to implement that. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services