Re: Should pg 11 use a lot more memory building an spgist index?
Amit Langote <langote_amit_f8@lab.ntt.co.jp>
From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@2ndquadrant.com>,
akorotkov@postgresql.org, bruno@wolff.to,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-10-31T01:50:19Z
Lists: pgsql-hackers
On 2018/10/30 21:27, Amit Langote wrote: > On Tue, Oct 30, 2018 at 7:11 PM Amit Langote >> I've tried to fix that with the attached patches. >> >> 0001 adds the ability for the callers of index_beginscan to specify a >> memory context. index_beginscan_internals switches to that context before >> calling ambeginscan and stores into a new field xs_scan_cxt of >> IndexScanData, but maybe storing it is unnecessary. >> >> 0002 builds on that and adds the ability for the callers of >> check_exclusion_or_unique_constraints to specify a memory context. Using >> that, it fixes the leak by teaching IndexCheckExclusion and >> ExecIndexInsertTuples to pass a memory context that's reset before calling >> check_exclusion_or_unique_constraints() for the next tuple. >> >> The following example shows that the patch works. >> >> With HEAD: >> >> create table foo (a int4range); >> alter table foo add exclude using spgist (a with &&); >> -- this consumes about 1GB >> insert into foo select int4range(i,i+1) from generate_series(1, 100000) i; >> alter table foo drop constraint foo_a_excl; >> -- this too >> alter table foo add exclude using spgist (a with &&); >> >> Patched: >> >> create table foo (a int4range); >> alter table foo add exclude using spgist (a with &&); >> -- memory consumption doesn't grow above 37MB >> insert into foo select int4range(i,i+1) from generate_series(1, 100000) i; >> alter table foo drop constraint foo_a_excl; >> -- ditto >> alter table foo add exclude using spgist (a with &&); > > Sorry I forgot to try the example with your patch. Maybe, it will > have more or less the same behavior as mine, although I didn't realize > that when I started writing my patch. Yep, I checked that fix-spgist-memory-leaks-1.patch posted upthread gives almost the same numbers, i.e., the maximum amount of memory consumed. Maybe, we don't need to spoil the interface of index_beginscan with the new memory context argument like my patch does if the simple following of its contract by amendscan would suffice. Thanks, Amit
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