On 16 January 2016 at 03:03, Robert Haas <robertmh...@gmail.com> wrote:
> 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. That sounds fine in theory, but where and how do you suppose we determine which expand function to call? Nothing exists in the catalogs to decide this currently. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
