On Tue, Feb 10, 2009 at 10:38 PM, Tom Lane <tgl@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.3040202@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