Re: Review: B-Tree emulation for GIN

The GIN_EXTRACT_VALUE macro returns a pointer to a static 'entries'
variable. That doesn't seem safe. Is it really never possible to have to
two GIN searches in a plan, both calling and using the value returned
by extractValue simultaneously? In any case that seems like a pretty
weak assumption.

You might want to declare extra_data as just "void *", instead of an
array of pointers. The data type implementation might want to store
something there that's not per-key, but applies to the whole query. I
see that you're passing it to comparePartial, but that seems to be just
future-proofing. What kind of a data type are you envisioning that would
make use of it? It seems that you could pass the same information in the
partial key Datum itself that extractQuery returns. You're currently
using it as a way to avoid some palloc's in gin_tsquery_consistent().
That seems like a pretty dirty hack. I doubt there's any meaningful
performance advantage from that, but if there is, I think you could use
a statically allocated array instead.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com