Re: Todo item: Support amgettuple() in GIN

On 11/29/2013 07:13 PM, Tom Lane wrote:
> Andreas Karlsson <andreas@proxel.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