From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruno Wolff III <bruno(at)wolff(dot)to> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Should pg 11 use a lot more memory building an spgist index? |
Date: | 2018-10-26 12:44:07 |
Message-ID: | 25927.1540557847@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Bruno Wolff III <bruno(at)wolff(dot)to> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Hmm, in my hands this produces the same size leak (~28GB) in either v10
>> or v11. In HEAD, somebody's made it even worse (~43GB). So this is
>> certainly pretty broken, but I'm not sure why it seems worse to you in
>> v11 than before.
> As a short term work around, could I create the index first and use
> insert statements, each in their own transaction, to get the table loaded
> with the index?
Yes; it might also be that you don't even need to break it up into
separate statements.
> Is the issue on Fedora taking very long to build a normal spgist index for
> network addresses worth pursuing separately, or is it likely to be the same
> underlying cause?
This issue only applies if it was an exclusion constraint. If you saw
slowness or bloat with a plain index, that would be worth investigating
separately.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Kellerer | 2018-10-26 13:12:26 | Different memory allocation strategy in Postgres 11? |
Previous Message | Andrew Gierth | 2018-10-26 12:27:42 | Re: Shell Command within function |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-10-26 13:14:26 | Re: PostgreSQL Limits and lack of documentation about them. |
Previous Message | Michael Paquier | 2018-10-26 12:08:13 | Re: [PATCH] Tab complete EXECUTE FUNCTION for CREATE (EVENT) TRIGGER |