| From: | Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru> | 
|---|---|
| To: | Anton Dignös <dignoes(at)inf(dot)unibz(dot)it> | 
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org | 
| Subject: | Re: IndexJoin memory problem using spgist and boxes | 
| Date: | 2018-03-05 18:46:04 | 
| Message-ID: | 28309a69-16bd-27f1-bcd7-b524778e2152@postgrespro.ru | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On 04.03.2018 20:20, Anton Dignös wrote:
> The better alternative may be to have two temporary memory contexts,
> one per-tuple for calling the inner consistent method and one
> per-index-scan for the traversal memory.
Yes, this seems to be a better way of fixing the problem without 
introducing regressions mentioned by Tom. We'd keep a separate traversal 
context in ScanOpaque and run most of the spgWalk in it, except calling 
storeRes in query context and the inner consistent method in short-lived 
context.
Also, I think it would be worthwhile to test the resulting patch with 
valgrind. The allocations are not very apparent in the code, so it's 
easy to miss something.
-- 
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2018-03-05 18:57:15 | Re: parallel append vs. simple UNION ALL | 
| Previous Message | Heikki Linnakangas | 2018-03-05 18:44:35 | Re: Optimize Arm64 crc32c implementation in Postgresql |