Re: GIN fast insert - Mailing list pgsql-hackers

From Tom Lane
Subject Re: GIN fast insert
Date
Msg-id 12795.1234379754@sss.pgh.pa.us
Whole thread Raw
In response to Re: GIN fast insert  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: GIN fast insert
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Next
From: Simon Riggs
Date:
Subject: Re: HotStandby vs. flatfile updates