On Sat, 2009-07-11 at 19:06 -0400, Tom Lane wrote:
> > Is it possible to re-add amgettuple to GIN, and just set the cost high
> We wouldn't have deleted it if it were practical to make it work.
Can you elaborate a little?
Following the thread, I see:
http://archives.postgresql.org/pgsql-hackers/2009-02/msg00532.php
"What would be wrong with letting it degrade to lossy? I suppose the
reason it's trying to avoid that is to avoid having to recheck all the
rows on that page when it comes time to do the index insertion; but
surely having to do that is better than having arbitrary, unpredictable
failure conditions."
And the next message refers to:
http://archives.postgresql.org/message-id/4974B002.3040202@sigaev.ru
"amgettuple interface hasn't possibility to work with page-wide result
instead of exact ItemPointer. amgettuple can not return just a block
number as amgetbitmap can."
I see why it's impractical to make it efficient, but the way I see it we
can make gingettuple just a wrapper around gingetbitmap, which just
iterates through the bitmap. It would not have any performance benefit
over gingetbitmap, obviously. But if my index constraints patch is going
to support GIN (which seems like an interesting application), I would
need to implement a function which does this anyway (efficiently or
not).
Regards,Jeff Davis
