On Tue, Jun 16, 2020 at 02:39:47PM +0900, Michael Paquier wrote:
On Mon, Jun 15, 2020 at 10:29:41PM +0900, Michael Paquier wrote:Attempting to run installcheck with 13~ and a value of work_mem lower than the default causes two failures, both related to incremental sorts (here work_mem = 1MB): 1) Test incremental_sort: @@ -4,12 +4,13 @@ select * from (select * from tenk1 order by four) t order by four, ten; QUERY PLAN ----------------------------------- - Sort + Incremental Sort Sort Key: tenk1.four, tenk1.ten + Presorted Key: tenk1.four -> Sort Sort Key: tenk1.four -> Seq Scan on tenk1 -(5 rows) +(6 rows)Looking at this one, it happens that this is the first test in incremental_sort.sql, and we have the following comment: -- When we have to sort the entire table, incremental sort will -- be slower than plain sort, so it should not be used. explain (costs off) select * from (select * from tenk1 order by four) t order by four, ten; When using such a low value of work_mem, why do we switch to an incremental sort if we know that it is going to be slower than a plain sort? Something looks wrong in the planner choice here.
I don't think it's particularly wrong. The "full sort" can't be done in memory with such low work_mem value, while the incremental sort can. So I think the planner choice is sane, it's more than the comment does not explicitly state this depends on work_mem too. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
