Le lundi 7 novembre 2022, 17:58:50 CET Pavel Luzanov a écrit : > > I can't see why an incrementalsort could be more expensive than a full > > sort, using the same presorted path. > > The only reason I can see is the number of buffers to read. In the plan > with incremental sort we read the whole index, ~190000 buffers. > And the plan with seq scan only required ~5000 (I think due to buffer > ring optimization).
What I meant here is that disabling seqscans, the planner still chooses a full sort over a partial sort. The underlying index is the same, it is just a matter of choosing a Sort node over an IncrementalSort node. This, I think, is wrong: I can't see how it could be worse to use an incrementalsort in that case. It makes sense to prefer a SeqScan over an IndexScan if you are going to sort the whole table anyway. But in that case we shouldn't. What happened before is that some sort of incremental sort was always chosen, because it was hidden as an implementation detail of the agg node. But now it has to compete on a cost basis with the full sort, and that costing is wrong in that case. Maybe the original costing code for incremental sort was a bit too pessimistic. -- Ronan Dunklau
