Re: Improving avg performance for numeric
От | Hadi Moshayedi |
---|---|
Тема | Re: Improving avg performance for numeric |
Дата | |
Msg-id | CAK=1=Wpn=jc3kULtiXXLi6D5nR4P8DvnGb90kXRRdhgMiObu9g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Improving avg performance for numeric (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Improving avg performance for numeric
|
Список | pgsql-hackers |
Hi Tom, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. Cool. I created a patch which adds an aggregate property to pg_aggregate, so the transition space is can be overridden. This patch doesn't contain the numeric optimizations. It uses "0" (meaning not-set) for all existing aggregates. I manual-tested it a bit, by changing this value for aggregates and observing the changes in plan. I also updated some docs and pg_dump. Does this look like something along the lines of what you meant? Thanks, -- Hadi
Вложения
В списке pgsql-hackers по дате отправления: