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.row...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
