From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Paul Ramsey <pramsey(at)cleverelephant(dot)ca> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Expanded Object Header and Flat Cache |
Date: | 2016-01-15 19:54:14 |
Message-ID: | 28508.1452887654@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Paul Ramsey <pramsey(at)cleverelephant(dot)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,
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Christian Ullrich | 2016-01-15 20:46:53 | Re: BUG #13854: SSPI authentication failure: wrong realm name used |
Previous Message | Paul Ramsey | 2016-01-15 19:39:50 | Expanded Object Header and Flat Cache |