Todo item: Support amgettuple() in GIN - Mailing list pgsql-hackers

From Andreas Karlsson
Subject Todo item: Support amgettuple() in GIN
Date
Msg-id 5297DC17.7000608@proxel.se
Whole thread Raw
Responses Re: Todo item: Support amgettuple() in GIN  (Antonin Houska <antonin.houska@gmail.com>)
Re: Todo item: Support amgettuple() in GIN  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

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.

So I looked into that first, and here is my explanation for why it is 
broken for partial matches. I am sending this to the mailing list to 
check if I am correct and if so update the todo list with this new 
information.

= Explanation

When doing normal matching the code simply traverses the matching 
posting tree in TID order.

When doing partial matching the code need to be able to return the union 
of all TIDs in all the matching posting trees in TID order (to be able 
to do AND and OR operations with multiple search keys later). It does 
this by traversing them posting tree after posting tree and collecting 
them all in a TIDBitmap which is later iterated over.

This TIDBitmap becomes lossy if it too many TIDs are added to it, and 
this case is what broke amgettuple for partial matches.

To fix this it seems to me that either lossy pages would need to be 
rescanned by gingettuple or a version of collectMatchBitmap needs to be 
written which merges the matched posting trees in another way, probably 
by iterating over all of them at the same time.

Does this diagnosis sound correct?

= Footnotes

1. 
http://www.postgresql.org/message-id/CA+TgmobZhfRJNyz-fyw5kDtRurK0HjWP0vtP5fGZLE6eVSWCQw@mail.gmail.com

-- 
Andreas Karlsson



pgsql-hackers by date:

Previous
From: Karsten Hilbert
Date:
Subject: Re: [GENERAL] pg_upgrade ?deficiency
Next
From: Robert Haas
Date:
Subject: Re: MultiXact truncation, startup et al.