Re: GIN fast insert

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