Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gG1TO-0003Xd-76 for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Oct 2018 12:44:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gG1TL-0001D5-Qm for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Oct 2018 12:44:15 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gG1TL-0001Cl-GL; Fri, 26 Oct 2018 12:44:15 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gG1TF-0001Bo-SF; Fri, 26 Oct 2018 12:44:13 +0000 Received: from pro.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w9QCi7hj007182; Fri, 26 Oct 2018 08:44:07 -0400 From: Tom Lane To: Bruno Wolff III cc: 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: <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> Comments: In-reply-to Bruno Wolff III message dated "Fri, 26 Oct 2018 06:23:14 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25926.1540557847.1@sss.pgh.pa.us> Date: Fri, 26 Oct 2018 13:44:07 +0100 Message-ID: <25927.1540557847@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Bruno Wolff III writes: > Tom Lane 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