Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.
От | David Rowley |
---|---|
Тема | Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. |
Дата | |
Msg-id | CAApHDvpbA4j-SWBbJn0dBvraGzh4RaDhdR2BL640k_R7MG+eAg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (Justin Pryzby <pryzby@telsasoft.com>) |
Список | pgsql-hackers |
On Mon, 27 Jul 2020 at 14:54, Justin Pryzby <pryzby@telsasoft.com> wrote: > > On Mon, Jul 27, 2020 at 10:48:45AM +1200, David Rowley wrote: > > On Wed, 1 Jul 2020 at 18:46, Jeff Davis <pgsql@j-davis.com> wrote: > > > > > > On Tue, Jun 30, 2020, 7:04 PM David Rowley <dgrowleyml@gmail.com> wrote: > > >> > > >> Does anyone have any objections to that being changed? > > > > > > That's OK with me. By the way, I'm on vacation and will catch up on these HashAgg threads next week. > > > > (Adding Justin as I know he's expressed interest in the EXPLAIN output > > of HashAgg before) > > Thanks. > > It's unrelated to hashAgg vs hashJoin, but I also noticed that this is shown > only conditionally: > > if (es->format != EXPLAIN_FORMAT_TEXT) > { > if (es->costs && aggstate->hash_planned_partitions > 0) > { > ExplainPropertyInteger("Planned Partitions", NULL, > aggstate->hash_planned_partitions, es); > > That was conditional since it was introduced at 1f39bce02: > > if (es->costs && aggstate->hash_planned_partitions > 0) > { > ExplainPropertyInteger("Planned Partitions", NULL, > aggstate->hash_planned_partitions, es); > } > > I think 40efbf870 should've handled this, too. I pushed that change along with all the other changes mentioned to the EXPLAIN ANALYZE format. David
В списке pgsql-hackers по дате отправления: