From: | Chris Withers <chris(at)withers(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: surprisingly slow creation of gist index used in exclude constraint |
Date: | 2020-05-15 15:03:19 |
Message-ID: | e0eef9a6-1361-13a2-2452-be2f4d215ac7@withers.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 14/05/2020 21:31, Tom Lane wrote:
> Chris Withers <chris(at)withers(dot)org> writes:
>> It has 4.1 million rows in it and while importing the data only
>> takes a couple of minutes, when I did a test load into the new
>> cluster, building the mkt_profile_period_col1_col4_col2_chan_excl
>> index for the exclude constraint took 15 hours.
>
> Don't recall for sure, but I think GIST index build is sensitive
> to the maintenance_work_mem setting; did you have that cranked up?
postgres=# show maintenance_work_mem;
maintenance_work_mem
----------------------
2GB
(1 row)
Would it be worth turning that up more? The server has ~130GB memory.
>> - failing that, what can I do to import and then create the index
>> in the background?
>
> CREATE INDEX CONCURRENTLY, perhaps.
How would I bring this into play with respect to the dump and load
cycle? Is there an option to pg_dump or something else I should use or
is this a case of awk'ing the create index in the dump?
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | PegoraroF10 | 2020-05-15 15:08:34 | Bug on version 12 ? |
Previous Message | Gabriele Bartolini | 2020-05-15 14:40:41 | Re: Inherited an 18TB DB & need to backup |