Hi, hackers!
I'd like to propose a patch which introduces a functionality to include additional columns to SPGiST index to increase speed of queries containing them due to making the scans index only in this case. To date this functionality was available in GiSt and btree, I suppose the same is useful in SPGiST also.
A few words on realisaton:
1. The patch is intended to be fully compatible with previous SPGiSt indexes so SpGist leaf tuple structure remains unchanged until the ending of key attribute. All changes are introduced only after it. Internal tuples remain unchanged at all.
2. Included data is added in the form very similar to heap tuple but unlike the later it should not start from MAXALIGN boundary. I.e. nulls mask (if exist) starts just after the key value (it doesn't need alignment). Each of included attributes start from their own typealign boundary. The goal is to make leaf tuples and therefore index more compact.
3. Leaf tuple header is modified to store additional per tuple flags:
a) is nullmask present - if there is at least one null value among included attributes of a tuple
(Note that this nullmask apply only to include attributes as nulls management for key attributes is already realised in SPGiSt by placing leafs with null keys in separate list not in the main index tree.)
b) is there variable length values among included. If there is no and key attribute is also fixed-length e.g. (kd-tree, quad-tree etc.) then leaf tuple processing can be speed up using attcacheoff.
These bits are incorporated into unused higher bits of nextOffset in the header SPGiST leaf tuple. Even if we have 64Kb pages and tuples of minimum 12 bytes (the length of the header on 32-bit architectures) + 4 bytes ItemIdData 14 bit for nextOffset is more than enough.
All this changes only affect private index structures so all outside behavior like WAL, vacuum etc will remain unchanged.
As usual I very much appreciate your feedback
--