Re: GIN fast insert - Mailing list pgsql-hackers

From Teodor Sigaev
Subject Re: GIN fast insert
Date
Msg-id 499466D2.4010808@sigaev.ru
Whole thread Raw
In response to Re: GIN fast insert  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: GIN fast insert
List pgsql-hackers
> 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@sigaev.ru
  WWW: http://www.sigaev.ru/
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_migrator and handling dropped columns
Next
From: Tom Lane
Date:
Subject: Re: DISCARD ALL failing to acquire locks on pg_listen