From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
Subject: | Re: Failures with installcheck and low work_mem value in 13~ |
Date: | 2020-06-16 05:39:47 |
Message-ID: | 20200616053947.GC5162@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2020-06-16 05:41:31 | Re: BufFileRead() error signalling |
Previous Message | Peter Geoghegan | 2020-06-16 05:31:13 | Re: language cleanups in code and docs |