From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruno Wolff III <bruno@wolff.to>
Cc: pgsql-general@lists.postgresql.org
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Should pg 11 use a lot more memory building an spgist index?
Date: Fri, 26 Oct 2018 13:44:07 +0100
Message-ID: <25927.1540557847@sss.pgh.pa.us> (raw)
In-Reply-To: <20181026112314.GA8199@wolff.to>
References: <20181024012314.GA27428@wolff.to>
<19003.1540370028@sss.pgh.pa.us>
<20181024083748.GA3296@wolff.to>
<19088.1540372871@sss.pgh.pa.us>
<20181025174306.GA3184@wolff.to>
<24288.1540545369@sss.pgh.pa.us>
<20181026112314.GA8199@wolff.to>
Bruno Wolff III <bruno@wolff.to> writes:
> Tom Lane <tgl@sss.pgh.pa.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-general@postgresql.org
Cc: tgl@sss.pgh.pa.us, bruno@wolff.to, pgsql-general@lists.postgresql.org, pgsql-hackers@lists.postgresql.org
Subject: Re: Should pg 11 use a lot more memory building an spgist index?
In-Reply-To: <25927.1540557847@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox