Re: [HACKERS] Print correct startup cost for the group aggregate.
От | Ashutosh Bapat |
---|---|
Тема | Re: [HACKERS] Print correct startup cost for the group aggregate. |
Дата | |
Msg-id | CAFjFpRfvJEsStm3trC7h_GGDPC-YMqaXMjGUHo5e4QMMtYRr5g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Print correct startup cost for the group aggregate. (Rushabh Lathia <rushabh.lathia@gmail.com>) |
Список | pgsql-hackers |
> > > I understood you reasoning of why startup_cost = input_startup_cost and not > input_total_cost for aggregation by sorting. But what I didn't understand is > how come higher startup cost for aggregation by sorting would force hash > aggregation to be chosen? I am not clear about this part. See this comment in cost_agg() * Note: in this cost model, AGG_SORTED and AGG_HASHED have exactly the * same totalCPU cost, but AGG_SORTED has lower startup cost. If the * input path is already sorted appropriately, AGG_SORTEDshould be * preferred (since it has no risk of memory overflow). AFAIU, if the input is already sorted, aggregation by sorting and aggregation by hashing will have almost same cost, the startup cost of AGG_SORTED being lower than AGG_HASHED. Because of lower startup cost, AGG_SORTED gets chosen by add_path() over AGG_HASHED path. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
В списке pgsql-hackers по дате отправления: