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-fyw5kdtrurk0hjwp0vtp5fgzle6evsw...@mail.gmail.com
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
