Hi,
When initializing an incremental sort node, we have the following as
of ExecInitIncrementalSort():
/*
* Incremental sort can't be used with either EXEC_FLAG_REWIND,
* EXEC_FLAG_BACKWARD or EXEC_FLAG_MARK, because we only one of many sort
* batches in the current sort state.
*/
Assert((eflags & (EXEC_FLAG_BACKWARD |
EXEC_FLAG_MARK)) == 0);
While I don't quite follow why EXEC_FLAG_REWIND should be allowed here
to begin with (because incremental sorts don't support rescans without
parameter changes, right?), the comment and the assertion are telling
a different story. And I can see that child nodes of an
IncrementalSort one use a set of eflags where these three are removed:
/*
* Initialize child nodes.
*
* We shield the child node from the need to support REWIND, BACKWARD, or
* MARK/RESTORE.
*/
eflags &= ~(EXEC_FLAG_REWIND | EXEC_FLAG_BACKWARD | EXEC_FLAG_MARK);
I can also spot one case in the regression tests where we actually pass
down a REWIND flag (see incremental_sort.sql) when initializing an
IncrementalSort node:
-- We force the planner to choose a plan with incremental sort on the right side
-- of a nested loop join node. That way we trigger the rescan code path.
set local enable_hashjoin = off;
set local enable_mergejoin = off;
set local enable_material = off;
set local enable_sort = off;
explain (costs off) select * from t left join (select * from (select *
from t order by a) v order by a, b) s on s.a = t.a where t.a in (1,
2);
select * from t left join (select * from (select * from t order by a)
v order by a, b) s on s.a = t.a where t.a in (1, 2);
Alexander, Tomas, any thoughts?
--
Michael
