On Fri, 9 Dec 2022 at 03:38, Tom Lane wrote:
> It's true that the cost attributed to the Agg node won't impact any
> live decisions in the plan level in which it appears. However, if
> that's a subquery, then the total cost attributed to the subplan
> could in principle affect plan choices in the
On Fri, 9 Dec 2022 at 01:12, David Geier wrote:
> Both plans were captured on 14.5, which is indeed prior to 1349d279.
>
> I disabled sequential scan to show that there's an alternative plan
> which is superior to the chosen plan: Index Only Scan is more expensive
> and takes longer than the Seq S
David Rowley writes:
> So, with the assumption that you've used 2 different versions to show
> this output, for post 1349d279, there does not seem to be much choice
> on how the aggregate is executed. What's your concern about the
> costings having to be accurate given there's no other plan choice
Hi David,
Thanks for the explanations and awesome that this was improved on already.
I didn't have this change on my radar.
On 12/8/22 11:40, David Rowley wrote:
This output surely must be from a version of PostgreSQL prior to
1349d279? I can't quite figure out why you've added a "SET
enable_
On Thu, 8 Dec 2022 at 22:06, David Geier wrote:
> The cost of an Aggregate node seems to be the same regardless of the
> input being pre-sorted or not. If however the input is not sorted, the
> Aggregate node must additionally perform a sort which can impact runtime
> significantly. Here is an exa
