Re: Should pg 11 use a lot more memory building an spgist index?
Bruno Wolff III <bruno@wolff.to>
From: Bruno Wolff III <bruno@wolff.to>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-general@lists.postgresql.org, pgsql-hackers@lists.postgresql.org
Date: 2018-10-26T11:23:14Z
Lists: pgsql-hackers
On Fri, Oct 26, 2018 at 10:16:09 +0100, Tom Lane <tgl@sss.pgh.pa.us> wrote: >Bruno Wolff III <bruno@wolff.to> writes: >> I have something that seems to produce it on rhel7. Fedora isn't working >> well either, but the difference may be due to postgresql.conf being >> different or some difference in the Fedora build. > >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? 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? I don't really need to get this working there, as that was just to help with testing. I could also try adjusting memory limits temporarily. If the leak is 28GB on a 32GB system I might be able to get the index built if less memory is tied up in other things. My workstation also has 32GB and the exclude index did build there with the postgresql.conf having lower memory limits.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix memory leak in repeated SPGIST index scans.
- 696b0c5fd0a8 12.0 landed
- 95015b1f8e8e 9.4.20 landed
- 92e371f9b143 10.6 landed
- 82dd1c271492 9.3.25 landed
- 558571afc7c4 9.6.11 landed
- 156a737a6b73 9.5.15 landed
- 2493e2c2d167 11.1 landed
-
Add support for nearest-neighbor (KNN) searches to SP-GiST
- 2a6368343ff4 12.0 cited