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
<david.rowley@2ndquadrant.com> 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
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
