Hi David,
>Typically, in the regression tests we've used enable_sort to force a
>HashAgg. There are certainly times when that's not good enough and you
>might also need to disabe enable_indexscan too, so I understand the
desire to add this GUC.
Thank you for the explanation.
I wasn't aware that e
On Wed, 11 Jun 2025 at 20:37, Tatsuro Yamada wrote:
> I created a regression test to check the enable_groupagg parameter in
> the new patch.
> To ensure plan stability, I disabled parallel query by setting the
> max_parallel_*
> parameters to 0.
>
> Any feedback is welcome.
Typically, in the reg
Hi Ashtosh and hackers,
> >Some of those instances are for plan stability, all of which need not be
> replicated. But some of them explicitly test sort based grouping. For rest
> of them hash based plan seems to be the best one, so explicit
> enable_groupagg = false is not needed. We will need so
Hi Ashutosh,
Thanks for your reply!
>I first thought enable_hashagg should be sufficient to choose one strategy
over the other. But that is not true, enable_hashagg = true allows both the
strategies, enable_hashagg = false disables just hash strategy. There's no
way to disable group agg alone. So
On Fri, Jun 6, 2025 at 1:29 PM Tatsuro Yamada wrote:
> Hi hackers,
>
> When I measured the execution time of a certain query with parallel query
> enabled and disabled, I found that the execution time was slower when
> parallel query was enabled.
>
> To improve the performance of the parallel que
Hi,
# Query Execution Results (Average of 3 measurements)
> - With parallel query: 39546 seconds
> - With parallel query and enable_groupagg turned off: 1115 seconds
>
Oops, I made a mistake. The correct execution time is:
- With parallel query:
