Re: Todo item: Support amgettuple() in GIN

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

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
http://www.postgresql.org/message-id/49AC300F.1050903@enterprisedb.com

Note that fixing the potential lossiness in scanning is not the only
roadblock to re-enabling amgettuple. Fast updates also pose problems:
http://www.postgresql.org/message-id/4974B002.3040202@sigaev.ru

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-11-29 17:21:19 Re: [RFC] overflow checks optimized away
Previous Message Marko Kreen 2013-11-29 16:52:41 Re: [PATCH 1/2] SSL: GUC option to prefer server cipher order