Man, I really shouldn't go on vacation for Christmas or, like, ever.
My email responses get way too slow.  Sorry.

On Tue, Dec 29, 2015 at 7:39 PM, David Rowley
<> wrote:
>> No, the idea I had in mind was to allow it to continue to exist in the
>> expanded format until you really need it in the varlena format, and
>> then serialize it at that point.  You'd actually need to do the
>> opposite: if you get an input that is not in expanded format, expand
>> it.
> Admittedly I'm struggling to see how this can be done. I've spent a good bit
> of time analysing how the expanded object stuff works.
> Hypothetically let's say we can make it work like:
> 1. During partial aggregation (finalizeAggs = false), in
> finalize_aggregates(), where we'd normally call the final function, instead
> flatten INTERNAL states and store the flattened Datum instead of the pointer
> to the INTERNAL state.
> 2. During combining aggregation (combineStates = true) have all the combine
> functions written in such a ways that the INTERNAL states expand the
> flattened states before combining the aggregate states.
> Does that sound like what you had in mind?

More or less.  But what I was really imagining is that we'd get rid of
the internal states and replace them with new datatypes built to
purpose.  So, for example, for string_agg(text, text) you could make a
new datatype that is basically a StringInfo.  In expanded form, it
really is a StringInfo.  When you flatten it, you just get the string.
When somebody expands it again, they again have a StringInfo.  So the
RW pointer to the expanded form supports append cheaply.

Robert Haas
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to