Re: Proposal: GiST constraints - Mailing list pgsql-hackers

From Teodor Sigaev
Subject Re: Proposal: GiST constraints
Date
Msg-id 484EF268.8000105@sigaev.ru
Whole thread Raw
In response to Re: Proposal: GiST constraints  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
>> In theory, any indexed value in index (for GiST, after compression) should fit 
>> into page at least.
> So are you saying we should dedicate one page multiplied by
> max_connections in shared memory? It's possible to do it that way, but

Yes, we could. Storing index keys in shared memory allows minimize access to 
heap. So, when new key is coming, you should check overlap with each stored keys 
in shared memory. For each check result will be one of the following points:
- keys are not overlapped: you don't need to go to the heap. Suppose, this will  be most frequent result in typical
usecases.
- keys may be overlapped (consistentFn returns true and needRecheck flag is  true): you should go to the heap to
consultwith original value (may be  visibility too)
 
- keys are overlapped (consistentFn returns true and needRecheck flag is false):  heap visit is needed only for
checkingvisibility
 


If you don't store keys in shared memory, then you should consult with heap for 
each stored key.
-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Automating our version-stamping a bit better
Next
From: "Nathan Boley"
Date:
Subject: Re: Proposal - improve eqsel estimates by including histogram bucket numdistinct statistics