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