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-26T14:54:37Z
Lists: pgsql-hackers
On Fri, Oct 26, 2018 at 13:44:07 +0100, Tom Lane <tgl@sss.pgh.pa.us> wrote: >Bruno Wolff III <bruno@wolff.to> writes: > >> 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. It was time to refresh the geolite data anyway so I tried this. I needed to turn memory_overcommit back on (0) to avoid an error, but the load went OK without the oom killer doing anything. So things are fully working again. Thanks for your help. >> 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. I'll start a seperate thread if I get something to reasonably ask about. The current dataset is probably a lot larger then needed to demonstrate the issue. The difference might be do to configuration or how Fedora built it. And I'll want to compare back to version 10. In the end I'll probably ask why it is slower in one case as opposed to the other and it might not even be a real bug.
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