Re: GIN fast insert

> But the *real* problem is that you simply can not guarantee that
> someone doesn't increase the size of the pending list between the time

If insertion process has bigger work_mem. Agree.

> What did you think of the idea of simply abandoning support for
> conventional indexscans in GIN? I agree that we could probably kluge
> something to make conventional scans still work reliably, but it seems
> to me that it'd be ugly, fragile, and quite possibly slow enough to not
> ever beat bitmap scans anyway.

I don't like this idea because it forbids conventional indexscans even with
fastupdate=off.

May readonly query change the index? Index doesn't use xmin/xmax/cmin/cmax
anyhow, so it doesn't depend on transaction state. If so, gingettuple could make
cleanup of pending list if it got lossy bitmap and repeat search. Although it
could be slow but it will never produce a failures and it will cause very rare
(and GIN could emit WARNING/NOTICE/LOG message). And this solution allows to
remove disabling of indexscan in gincostestimate.

--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/