From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: GiST constraints |
Date: | 2008-06-10 21:30:16 |
Message-ID: | 484EF268.8000105@sigaev.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 consult with original value (may be
visibility too)
- keys are overlapped (consistentFn returns true and needRecheck flag is false):
heap visit is needed only for checking visibility
If you don't store keys in shared memory, then you should consult with heap for
each stored key.
--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Boley | 2008-06-10 21:31:01 | Re: Proposal - improve eqsel estimates by including histogram bucket numdistinct statistics |
Previous Message | Tom Lane | 2008-06-10 21:15:39 | Re: Automating our version-stamping a bit better |