From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Wanted: jsonb on-disk representation documentation |
Date: | 2014-05-06 22:45:39 |
Message-ID: | CAM3SWZSGePypn2Ko5Zosj9CcR6589M3G69Hq0sPUVXz73RszeA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 6, 2014 at 3:37 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> That might or might not be true. I don't really remember. Documentation
> about the on-disk format is the one thing I am sure about that's not
> done.
I think it would be best to do that with reference to a concrete
example. As I said, I'll work on a patch.
> The reviews I did were really cursory reviews, nothing thorough. There's
> large parts of the code (e.g. jsonb_gin.c) I didn't even look at. And
> others I don't really understand. I also didn't have time to look at the
> later versions. The code did improve, don't get me wrong. Otherwise I'd
> have been very vocal about this when committed.
> But it's still pretty hard to read/understand code. Which imo is
> problematic for a feature touted being absolutely critical for postgres'
> success. If other's want a taste, take a peek at
> findJsonbValueFromSuperHeader()'s code.
I don't really know what to say to that. Lots of code in Postgres is
complicated, especially if you look at one particular function without
some wider context. Is your objection that the complexity is
incidental rather than essential? If so, how?
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2014-05-06 22:47:41 | Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers |
Previous Message | Tom Lane | 2014-05-06 22:39:37 | Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation) |