Re: GIN fast insert

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: GIN fast insert
Дата
Msg-id 12795.1234379754@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: GIN fast insert  (Teodor Sigaev <teodor@sigaev.ru>)
Ответы Re: GIN fast insert
Список pgsql-hackers
Teodor Sigaev <teodor@sigaev.ru> writes:
> Robert Haas wrote:
>> Why would the new work_mem need to be 10x smaller than the old work mem?

> That is is way to get GIN's error emitted. Work_mem should be decreased 
> to catch a chance to get lossy tidbitmap.

But it only has to be marginally lower, not 10x lower.  And there are
plenty of scenarios where different backends might be running with
different work_mem settings.

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
that someone else commits to an indexscan plan and the time that they
execute that plan.  This scheme will result in random failures for
concurrent inserts/selects, and that's not acceptable.

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.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: HotStandby vs. flatfile updates