Re: Review: B-Tree emulation for GIN

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Review: B-Tree emulation for GIN
Date: 2009-02-04 17:22:35
Message-ID: 4989CEDB.9080306@sigaev.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Looked at this a bit ... do you think it's really a good idea to remove
> the strategy number argument of comparePartial? The argument given in
> the docs for it is that it might be needed to determine when to end the
> scan, and that still seems plausible to me.
Strategy number is not removed, it's replaced by pointer to opclass-specific
data on per key basis. Actually, partial match feature is new for 8.4 and there
is no any compatibility problem. None of existing opclasses (except
contrib/btree_gin) uses strategy number in comparePartial.

> The description of extractQuery's extra_data parameter seems confusing
> too. AFAICS it is incorrect, or at least misleading, to describe it as
> void ** extra_data[]; it is really void ***extra_data, because there is
> only one object there not an array.

It's really array, see fillScanKey() in ginscan.c, line 61 of patched file.
extractQuery could provide data for each returned key.

--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-02-04 17:22:47 Re: add_path optimization
Previous Message David E. Wheeler 2009-02-04 17:22:23 Re: LIMIT NULL