Paul Ramsey <pram...@cleverelephant.ca> writes: > I've been working through the expanded object code to try and get a > demonstration of it working with PostGIS (still having some problems, > but it's a learning experience). On an unrelated from, I noticed in > the array expanded code, that the array code is managing its own copy > of a cache of the flat representation and flat size,
> https://github.com/postgres/postgres/blob/cf7dfbf2d6c5892747cd6fca399350d86c16f00f/src/backend/utils/adt/array_expanded.c#L247-L253 > This seems like generic code, which any implementor is going to end up > copying (after seeing it, and seeing how often the flatten size > callback is being hit while debugging code, it seems like an obvious > next thing to add to my expanded representation, once I get things > working). Well, mumble, I'm not so sure. In the array code that's not really a cache, but a halfway point between the flat representation and a fully deconstructed representation, which is useful mainly because it saves cycles while un-flattening. Being able to return it as-is while flattening is just a nice bonus AFAICS; I doubt that's a big win in practical use. And in other datatypes it might be much less feasible to do that. Before leaving Salesforce I did another expanded-object implementation for them, of a datatype that was basically much like hstore (key-value thing). The expanded representation was a dynahash hashtable, and there was no equivalent of the array code's internal flat values because it didn't map to the dynahash form at all. Besides which their use-case was such that the flattened representation was hardly ever needed. Caching the flat size does seem like a near universally-useful optimization, because otherwise you have to compute it twice while flattening. But there's not enough there to justify trying to share code, AFAICS; most of the trickiness is in knowing when you've invalidated the cached flat size, and that's going to be pretty operation-specific. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
