| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Top-N sorts in EXPLAIN, row count estimates, and parallelism |
| Date: | 2019-05-23 22:43:40 |
| Message-ID: | CAH2-Wzn8pd4_QeYO4nLMHsY4xGAsEQBy4X-e-rj_jfUD2XuU2g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, May 23, 2019 at 3:31 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-05-23 22:45:19 | Re: ClosePipeStream failure ignored in pg_import_system_collations |
| Previous Message | Thomas Munro | 2019-05-23 22:43:27 | Re: Question about BarrierAttach spinlock |