Re: Improving avg performance for numeric - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Improving avg performance for numeric
Date
Msg-id 8165.1363715889@sss.pgh.pa.us
Whole thread Raw
In response to Re: Improving avg performance for numeric  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Improving avg performance for numeric  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: Improving avg performance for numeric  (Hadi Moshayedi <hadi@moshayedi.net>)
List 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 by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Enabling Checksums
Next
From: Tom Lane
Date:
Subject: Re: Enabling Checksums