Re: Improving avg performance for numeric

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Improving avg performance for numeric
Дата
Msg-id 8165.1363715889@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Improving avg performance for numeric  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Improving avg performance for numeric  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: Improving avg performance for numeric  (Hadi Moshayedi <hadi@moshayedi.net>)
Список pgsql-hackers
I wrote:
> [ looks at patch... ]  Oh, I see what's affecting the plan: you changed
> the aggtranstypes to internal for a bunch of aggregates.  That's not
> very good, because right now the planner takes that to mean that the
> aggregate could eat a lot of space.  We don't want that to happen for
> these aggregates, I think.

After thinking about that for awhile: if we pursue this type of
optimization, what would probably be appropriate is to add an aggregate
property (stored in pg_aggregate) that allows direct specification of
the size that the planner should assume for the aggregate's transition
value.  We were getting away with a hardwired assumption of 8K for
"internal" because the existing aggregates that used that transtype all
had similar properties, but it was always really a band-aid not a proper
solution.  A per-aggregate override could be useful in other cases too.

This was looking like 9.4 material already, but adding such a property
would definitely put it over the top of what we could think about
squeezing into 9.3, IMO.
        regards, tom lane



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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Enabling Checksums
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Enabling Checksums