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