Обсуждение: Schizophrenic coding in gin_extract_jsonb(_hash)

Поиск
Список
Период
Сортировка

Schizophrenic coding in gin_extract_jsonb(_hash)

От
Tom Lane
Дата:
Would someone care to defend this code?
   int            total = 2 * JB_ROOT_COUNT(jb);
   ...
   if (total == 0)   {       *nentries = 0;       PG_RETURN_POINTER(NULL);   }
   ...
   while ((r = JsonbIteratorNext(&it, &v, false)) != WJB_DONE)   {       if (i >= total)       {           total *= 2;
        entries = (Datum *) repalloc(entries, sizeof(Datum) * total);       }
 

The early-exit code path supposes that JB_ROOT_COUNT is absolutely
reliable as an indicator that there's nothing in the jsonb value.
On the other hand, the realloc logic inside the iteration loop implies
that JB_ROOT_COUNT is just an untrustworthy estimate.  Which theory is
correct?  And why is there not a comment to be seen anywhere?  If the code
is correct then this logic is certainly worthy of a comment or three.
        regards, tom lane



Re: Schizophrenic coding in gin_extract_jsonb(_hash)

От
Peter Geoghegan
Дата:
On Tue, May 6, 2014 at 8:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> The early-exit code path supposes that JB_ROOT_COUNT is absolutely
> reliable as an indicator that there's nothing in the jsonb value.
> On the other hand, the realloc logic inside the iteration loop implies
> that JB_ROOT_COUNT is just an untrustworthy estimate.  Which theory is
> correct?  And why is there not a comment to be seen anywhere?  If the code
> is correct then this logic is certainly worthy of a comment or three.

JsonbIteratorNext() is passed "false" as its skipNested argument. It's
recursive.

-- 
Peter Geoghegan



Re: Schizophrenic coding in gin_extract_jsonb(_hash)

От
Tom Lane
Дата:
Peter Geoghegan <pg@heroku.com> writes:
> On Tue, May 6, 2014 at 8:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The early-exit code path supposes that JB_ROOT_COUNT is absolutely
>> reliable as an indicator that there's nothing in the jsonb value.
>> On the other hand, the realloc logic inside the iteration loop implies
>> that JB_ROOT_COUNT is just an untrustworthy estimate.  Which theory is
>> correct?  And why is there not a comment to be seen anywhere?  If the code
>> is correct then this logic is certainly worthy of a comment or three.

> JsonbIteratorNext() is passed "false" as its skipNested argument. It's
> recursive.

And?

I think you're just proving the point that this code is woefully
underdocumented.  If there were, somewhere, some comment explaining
what the heck JB_ROOT_COUNT actually counts, maybe I wouldn't be asking
this question.  jsonb.h is certainly not divulging any such information.
        regards, tom lane



Re: Schizophrenic coding in gin_extract_jsonb(_hash)

От
Heikki Linnakangas
Дата:
On 05/07/2014 06:27 PM, Tom Lane wrote:
> I think you're just proving the point that this code is woefully
> underdocumented.  If there were, somewhere, some comment explaining
> what the heck JB_ROOT_COUNT actually counts, maybe I wouldn't be asking
> this question.  jsonb.h is certainly not divulging any such information.

After having reverse-engineered the convertJsonb code, I think I can 
explain what JB_ROOT_COUNT is.

If the root of the Jsonb datum is an array, it's the number of elements 
in that top-level array. If it's an object, it's the number of key/value 
pairs in that top-level object. Some of the elements of that array (or 
values of the object) can be arrays or objects themselves.

gin_extract_jsonb recursively extracts all the elements, keys and values 
of any sub-object too, but JB_ROOT_COUNT only counts the top-level elements.

(I hope this is made a bit more clear in the comments I added in the 
patch I posted this morning)

- Heikki



Re: Schizophrenic coding in gin_extract_jsonb(_hash)

От
Tom Lane
Дата:
Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> gin_extract_jsonb recursively extracts all the elements, keys and values 
> of any sub-object too, but JB_ROOT_COUNT only counts the top-level elements.

Got it.  So if the top level is empty, we can exit early, but otherwise we
use its length * 2 as a guess at how big the output will be; which will
be right if it's an object without further substructure, and otherwise
might need enlargement.

> (I hope this is made a bit more clear in the comments I added in the 
> patch I posted this morning)

Didn't read that yet, but will incorporate this info into the jsonb_gin
patch I'm working on.
        regards, tom lane