Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.
От | Justin Pryzby |
---|---|
Тема | Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. |
Дата | |
Msg-id | 20200727025402.GL4286@telsasoft.com обсуждение исходный текст |
Ответ на | Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.
Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. |
Список | pgsql-hackers |
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. -- Justin
В списке pgsql-hackers по дате отправления: