| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. |
| Date: | 2020-07-28 03:20:45 |
| Message-ID: | CAH2-WznnjYTa1wUYdiQTrmyi3wY8UNggnxUsKYDYLCCke1cMwg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jul 27, 2020 at 5:54 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> hmm. I'm not sure. I think this should follow the same logic as what
> "Disk Usage" follows, and right now we don't show Disk Usage unless we
> spill. Since we only use partitions when spilling, I don't think it
> makes sense to show the estimated partitions when we don't plan on
> spilling.
I'm confused about what the guiding principles for EXPLAIN ANALYZE
output (text or otherwise) are.
> I think if we change this then we should change Disk Usage too.
> However, I don't think we should as Sort will only show "Disk" if the
> sort spills. I think Hash Agg should follow that.
I don't follow your remarks here.
Separately, I wonder what your opinion is about what should happen for
the partial sort related EXPLAIN ANALYZE format open item, described
here:
ISTM that EXPLAIN ANALYZE for incremental sort manages to show the
same information as the sort case, aggregated across each tuplesort in
a fairly sensible way.
(No activity over on the incremental sort thread, so I thought I'd ask
again here, while I was reminded of that issue.)
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-07-28 03:27:40 | Re: stress test for parallel workers |
| Previous Message | Justin Pryzby | 2020-07-28 03:01:45 | Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. |