Re: Todo item: Support amgettuple() in GIN

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andreas Karlsson <andreas(at)proxel(dot)se>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Todo item: Support amgettuple() in GIN
Date: 2013-11-29 17:38:13
Message-ID: 5298D105.1080302@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/29/2013 07:13 PM, Tom Lane wrote:
> Andreas Karlsson <andreas(at)proxel(dot)se> writes:
>> I decided to look into how much work implementing the todo item about
>> supporting amgettuple in GIN would be, since exclusion constraints on
>> GIN would be neat. Robert Haas suggested a solution[1], but to fix it we
>> also need to look into why the commit message mentions that it did not
>> work anyway with the partial matches.
>> ...
>> This TIDBitmap becomes lossy if it too many TIDs are added to it, and
>> this case is what broke amgettuple for partial matches.
>
> Right, see
> https://urldefense.proofpoint.com/v1/url?u=http://www.postgresql.org/message-id/49AC300F.1050903%40enterprisedb.com&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=xGch4oNJbpD%2BKPJECmgw4SLBhytSZLBX7UnkZhtNcpw%3D%0A&m=OqhHlGFG81LH1EqJLzTW8HuXdXslGEL%2FPu1f27HxV%2Bs%3D%0A&s=9f3fad064e2845bd2b99c85f684d237fbe96e542081e4b2dc49b1fe51f91f144
>
> Note that fixing the potential lossiness in scanning is not the only
> roadblock to re-enabling amgettuple. Fast updates also pose problems:
> https://urldefense.proofpoint.com/v1/url?u=http://www.postgresql.org/message-id/4974B002.3040202%40sigaev.ru&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=xGch4oNJbpD%2BKPJECmgw4SLBhytSZLBX7UnkZhtNcpw%3D%0A&m=OqhHlGFG81LH1EqJLzTW8HuXdXslGEL%2FPu1f27HxV%2Bs%3D%0A&s=0e08a781fcc17a3d68ce247344a3499a23a9f545b937f254439dadfaf7b9b8ab
>
> Half of that is basically the same lossiness problem, but the other
> half is that we're relying on the bitmap to suppress duplicate reports
> of the same TID. It's fairly hard to see how you'd avoid that without
> creating other problems.
>
> Note that Robert's proposed solution is no solution, because it just
> puts you right back in the bind of needing guaranteed non-lossy
> storage of a TID set that might be too big to fit in memory.

You can always call amgetbitmap, and return the tuples from the bitmap
one by one. For a lossy result, re-check all tuples on the page. IOW, do
a bitmap index + heap scan. You could do that within indexam.c, and
present the familiar index_getnext() interface for callers. Or you could
modify the exclusion constraint code to do that if amgettuple is not
available

- Heikki

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Karlsson 2013-11-29 17:43:33 Re: Todo item: Support amgettuple() in GIN
Previous Message Bruce Momjian 2013-11-29 17:36:18 Re: Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block