Re: [HACKERS] Print correct startup cost for the group aggregate. - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Print correct startup cost for the group aggregate.
Date
Msg-id CA+TgmobJFgq26mD3fjh6mVnyA7zLEHS09U2V4gYunjv6Vr0aTg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Print correct startup cost for the group aggregate.  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
List pgsql-hackers
On Sun, Mar 5, 2017 at 11:32 PM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:
>> I think there have been
>> previous discussions of switching over to the practice for which you
>> are advocating here, but my impression (without researching) is that
>> the current practice is more like what Rushabh did.
>
> I am not sure Rushabh's approach is correct. Here's the excerpt from my mail.
>
>>> The reason the reason why startup_cost = input_startup_cost and not
>>> input_total_cost for aggregation by sorting is we don't need the whole
>>> input before the Group/Agg plan can produce the first row.
>
> With Rushabh's approach the startup cost of aggregation by sorting
> would be way higher that it's right now. Secondly, it would match that
> of hash aggregation and thus forcing hash aggregation to be chosen in
> almost all the cases.

You're right.  I'm wrong.  I take it all back.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API inlibpqwalreceiver
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Cost model for parallel CREATE INDEX