Re: GIN fast insert

Поиск
Список
Период
Сортировка
От Teodor Sigaev
Тема Re: GIN fast insert
Дата
Msg-id 499466D2.4010808@sigaev.ru
обсуждение исходный текст
Ответ на Re: GIN fast insert  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: GIN fast insert
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_migrator and handling dropped columns
Следующее
От: Tom Lane
Дата:
Сообщение: Re: DISCARD ALL failing to acquire locks on pg_listen