Re: [HACKERS] Unusable SP-GiST index

2017-01-03 Thread Tom Lane
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.

Re: [HACKERS] Unusable SP-GiST index

2016-12-30 Thread Tom Lane
I wrote: > Maybe we should redefine the API as involving a TupleTableSlot that > the AM is supposed to fill --- basically, moving StoreIndexTuple > out of the common code in nodeIndexonlyscan.c and requiring the AM > to do that work. The possible breakage of third-party code is a > bit annoying,

Re: [HACKERS] Unusable SP-GiST index

2016-12-30 Thread Tom Lane
Vik Fearing writes: > While trying to find a case where spgist wins over btree for text, I > came across the following behavior which I would consider a bug: > CREATE TABLE texts (value text); > INSERT INTO texts SELECT repeat('a', (2^20)::integer); > CREATE INDEX ON texts