Re: Review: B-Tree emulation for GIN

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Review: B-Tree emulation for GIN
Date: 2009-04-04 22:25:10
Message-ID: 24052.1238883910@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
> [ fixes for the GIN stuff I complained about before ]

This all looks good to me, please apply. One little suggestion:

! /*
! * entryRes array is used for:
! * - as an argument for consistentFn
! * - entry->curItem with corresponding key->entryRes[i] == false are greater
! * than key->curItem, so next loop/call they should be renewed
! * by entryGetItem(). So, we need to set up an array before
! * checking of lossy page.
! */

pgindent will reflow this comment block, since it's not at the left
margin. To keep the formatting looking good you'll need to add /*--------

>> * I'd also like to come to some agreement about getting rid of the
>> fail-on-NULL-scankey problem in newScanKey(). As I noted in the
>> comment there, we could make that work cleanly if we are willing to
>> assume that all GIN-indexable operators are strict. We already assume
>> the same for hash and btree operators, so it doesn't seem like a big
>> problem to do this, but I wonder if there are any objections.

> Agree. I changed the GIN code, but don't know where is other places
> to change to fixate this agreement.

I don't think there is anything else that needs to be done for that.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-04-04 22:58:04 Re: Duplicate key value error
Previous Message Tom Lane 2009-04-04 22:08:01 Re: monitoring-stats.html documentation