From: | Anastasia Lubennikova <lubennikovaav(at)gmail(dot)com> |
---|---|
To: | Fabrízio Mello <fabriziomello(at)gmail(dot)com> |
Cc: | Thom Brown <thom(at)linux(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Index-only scans for GiST. |
Date: | 2015-02-27 14:19:47 |
Message-ID: | CAP4vRV40pq-9iAD7eEHnrk_19jkuJ-KzE0raMj3kW2QBvY+aCg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I add MemoryContext listCxt to avoid memory leak. listCxt is created once
in gistrescan (only for index-only scan plan ) and reseted when scan of the
leaf page is finished.
I do not sure if the problem was completely solved, so I wait for feedback.
* What's the reason for turning GISTScanOpaqueData.pageData from an array
to a List?
This array is field of structure GISTScanOpaqueData. Memory for that
structure allocated in function gistbeginscan(). The array is static so
it's declared only one time in structure:
GISTSearchHeapItem pageData [BLCKSZ/sizeof(IndexTupleData)]
But how could we know size of array if we don't know what data would be
returned? I mean type and amount.
I asked Alexander about that and he offered me to use List instead of Array.
Attachment | Content-Type | Size |
---|---|---|
indexonlyscan_gist_2.2.patch | application/octet-stream | 36.6 KB |
indexonlyscan_gist_docs.patch | application/octet-stream | 6.3 KB |
test_performance.sql | application/octet-stream | 1023 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Marc Cousin | 2015-02-27 14:27:10 | Re: star schema and the optimizer |
Previous Message | Tom Lane | 2015-02-27 14:08:27 | Re: star schema and the optimizer |