Stephen Frost <sfr...@snowman.net> writes:
> I agree that we need to avoid changing jsonb's on-disk representation.
... post-release, I assume you mean.
> Have I missed where a good suggestion has been made about how to do that
> which preserves the binary-search capabilities and doesn't make the code
> much more difficult?
We don't have one yet, but we've only been thinking about this for a few
hours.
> Trying to move the header to the end just for the
> sake of this doesn't strike me as a good solution as it'll make things
> quite a bit more complicated. Is there a way we could interleave the
> likely-compressible user data in with the header instead?
Yeah, I was wondering about that too, but I don't immediately see how to
do it without some sort of preprocessing step when we read the object
(which'd be morally equivalent to converting a series of lengths into a
pointer array). Binary search isn't going to work if the items it's
searching in aren't all the same size.
Having said that, I am not sure that a preprocessing step is a
deal-breaker. It'd be O(N), but with a pretty darn small constant factor,
and for plausible sizes of objects I think the binary search might still
dominate. Worth investigation perhaps.
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
