Re: Unusable SP-GiST index

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

In response to

Browse pgsql-hackers by date

  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)