On Tue, Feb 10, 2009 at 10:38 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> I think this code needs to be somehow rewritten to make things degrade >> gracefully when the pending list is long - I'm not sure what the best >> way to do that is. Inventing a new data structure to store TIDs that >> is never lossy seems like it might work, but you'd have to think about >> what to do if it got too big. > > 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.
No, I don't think that's it. See here, beginning with "the problem with lossy tbm has two aspects": http://archives.postgresql.org/message-id/4974b002.3040...@sigaev.ru > It strikes me that part of the issue here is that the behavior of this > code is much better adapted to the bitmap-scan API than the traditional > indexscan API. Since GIN doesn't support ordered scan anyway, I wonder > whether it wouldn't be more sensible to simply allow it to not offer > the traditional API. It should be easy to make the planner ignore plain > indexscan plans for an AM that didn't support them. If that doesn't lead to a performance degradation, I think it would be a good idea. It certainly seems like it would allow this patch to be a LOT simpler, cleaner, and more robust. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
