Re: cost_agg() with AGG_HASHED does not account for startup costs
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: cost_agg() with AGG_HASHED does not account for startup costs |
| Дата | |
| Msg-id | 24373.1438696491@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | cost_agg() with AGG_HASHED does not account for startup costs (David Rowley <david.rowley@2ndquadrant.com>) |
| Ответы |
Re: cost_agg() with AGG_HASHED does not account for startup costs
|
| Список | pgsql-hackers |
David Rowley <david.rowley@2ndquadrant.com> writes:
> During working on allowing the planner to perform GROUP BY before joining
> I've noticed that cost_agg() completely ignores input_startup_cost
> when aggstrategy == AGG_HASHED.
Isn't your proposed patch double-counting the input startup cost?
input_total_cost already includes that charge. The calculation
reflects the fact that we have to read all of the input before we
can deliver any aggregated results, so the time to get the first
input row isn't really interesting.
If this were wrong, the PLAIN costing path would also be wrong, but
I don't think that either one is.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера