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: | Raw Message | Whole Thread | 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) |