| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Vik Fearing <vik(at)2ndquadrant(dot)fr> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Unusable SP-GiST index |
| Date: | 2017-01-04 00:21:36 |
| Message-ID: | 18107.1483489296@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote:
> After looking a bit at gist and sp-gist, neither of them would find that
> terribly convenient; they really want to create one blob of memory per
> index entry so as to not complicate storage management too much. But
> they'd be fine with making that blob be a HeapTuple not IndexTuple.
> So maybe the right approach is to expand the existing API to allow the
> AM to return *either* a heap or index tuple; that could be made to not
> be an API break.
Here's a draft patch along those lines. With this approach, btree doesn't
need to be touched at all, since what it's returning certainly is an
IndexTuple anyway. I fixed both SPGIST and GIST to use HeapTuple return
format. It's not very clear to me whether GIST has a similar hazard with
very large return values, but it might, and it's simple enough to change.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| indexonlyscan-can-return-heaptuple-1.patch | text/x-diff | 17.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-01-04 00:39:16 | Re: Cluster wide option to control symbol case folding |
| Previous Message | Peter Geoghegan | 2017-01-03 23:53:59 | Re: Parallel tuplesort (for parallel B-Tree index creation) |