Re: Review: B-Tree emulation for GIN

Teodor Sigaev wrote:
>> 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 
> 
> wildspeed module (http://www.sigaev.ru/cvsweb/cvsweb.cgi/wildspeed/) - 
> for each key from it's needed to store some info. Right now it's coded 
> directly in Datum, but it looks ugly (at least for me).

Ok, I guess it's best to leave it as you had in the patch then.

>> 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.
> 
> It's easy to un-dirty that hack, but before I'd like to see your 
> comments about thoughts above.

Yeah, please revert that hack.

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