| 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 |