Re: Aggregate node doesn't include cost for sorting

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Aggregate node doesn't include cost for sorting
Дата
Msg-id 103529.1670510335@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Aggregate node doesn't include cost for sorting  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Aggregate node doesn't include cost for sorting  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-hackers
David Rowley <dgrowleyml@gmail.com> 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?

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 outer query.  So there
is a valid argument for wanting to try to get it right.

Having said that, I think that the actual impact on outer-level choices
is usually minimal.  So it didn't bother me that we swept this under
the rug before --- and I'm pretty sure that we're sweeping similar
things under the rug elsewhere in top-of-query planning.  However,
given 1349d279 it should surely be true that the planner knows how many
sorts it's left to be done at runtime (a number we did not have at hand
before).  So it seems like it ought to be simple enough to account for
this effect more accurately.  I'd be in favor of doing so if it's
simple and cheap to get the numbers.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Reid Thompson
Дата:
Сообщение: Re: Add tracking of backend memory allocated to pg_stat_activity
Следующее
От: Dean Rasheed
Дата:
Сообщение: Documenting MERGE INTO ONLY ...