Re: GIN fast insert - Mailing list pgsql-hackers

From Robert Haas
Subject Re: GIN fast insert
Date
Msg-id 603c8f070902110705w259bcf59u2724aefa8d6c7ce7@mail.gmail.com
Whole thread Raw
In response to Re: GIN fast insert  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: GIN fast insert  (Teodor Sigaev <teodor@sigaev.ru>)
List pgsql-hackers
> I believe that user could get GIN's error about work_mem only intentionally:
> - turn off autovacuum

Meanwhile, in the other thread, we're having a discussion about people
wanting to do exactly this on a database-wide basis during peak load
hours...

> - set big work_mem
> - populate table with GIN index (by needed number of insertion)
> - prepare query which will return a lot of results (possibly, with
> seqscan=off because cost of scan of pending list grows fast)
> - decrease work_mem for at least ten times
> - execute query

Why would the new work_mem need to be 10x smaller than the old work mem?

...Robert


pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: GIN fast insert
Next
From: Tom Lane
Date:
Subject: Re: Copy PlannerInfo structure