Re: Top-N sorts in EXPLAIN, row count estimates, and parallelism - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Top-N sorts in EXPLAIN, row count estimates, and parallelism
Date
Msg-id CAH2-Wzn8pd4_QeYO4nLMHsY4xGAsEQBy4X-e-rj_jfUD2XuU2g@mail.gmail.com
Whole thread Raw
In response to Re: Top-N sorts in EXPLAIN, row count estimates, and parallelism  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Top-N sorts in EXPLAIN, row count estimates, and parallelism  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-hackers
On Thu, May 23, 2019 at 3:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Given the way that's implemented, I doubt that we can report it
> reliably in EXPLAIN.

Does it have to be totally reliable?

cost_sort() costs sorts as top-N heapsorts. While we cannot make an
iron-clad guarantee that it will work out that way from within
tuplesort.c, that doesn't seem like it closes off the possibility of
more informative EXPLAIN output. For example, can't we at report that
the tuplesort will be "bounded" within EXPLAIN, indicating that we
intend to attempt to sort using a top-N heap sort (i.e. we'll
definitely do it that way if there is sufficient work_mem)?

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Question about BarrierAttach spinlock
Next
From: Tom Lane
Date:
Subject: Re: ClosePipeStream failure ignored in pg_import_system_collations