On 11/29/2013 01:13 AM, Andreas Karlsson wrote:
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
On 11/29/2013 09:54 AM, Antonin Houska wrote:
On 11/29/2013 01:13 AM, Andreas Karlsson wrote:
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
On 11/29/2013 01:57 PM, Andreas Karlsson wrote:
On 11/29/2013 09:54 AM, Antonin Houska wrote:
On 11/29/2013 01:13 AM, Andreas Karlsson wrote:
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
Andreas Karlsson andr...@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
On 11/29/2013 07:13 PM, Tom Lane wrote:
Andreas Karlsson andr...@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
On 11/29/2013 06:13 PM, Tom Lane wrote:
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.
The solution should work if we could guarantee that a
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
