Re: Failures with installcheck and low work_mem value in 13~

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Failures with installcheck and low work_mem value in 13~
Дата
Msg-id 20200616053947.GC5162@paquier.xyz
обсуждение исходный текст
Ответ на Failures with installcheck and low work_mem value in 13~  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Failures with installcheck and low work_mem value in 13~  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: language cleanups in code and docs
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: BufFileRead() error signalling