Re: SP-GiST for ranges based on 2d-mapping and quad-tree

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Also, I wonder if we really need to reconstruct the "previous" value in 
> a RANGESTRAT_ADJACENT search. ISTM we only need to remember which of the 
> two lines we are chasing. For example, if you descend to quadrant 2 
> because there might be a point there that lies on the horizontal line, 
> but we already know that there can't be any points there lie on the 
> vertical line, you only need to remember that, not the whole centroid 
> from the previous level. Does the SP-GiST API require the 
> "reconstructed" values stored by inner_consistent to be of the correct 
> datatype, or can it store any Datums in the array?

They have to match the attribute type, at least as to storage details
(typbyval/typlen), because the core uses datumCopy to copy them around.

We could possibly extend the API to allow a different type to be used
for this, but then it wouldn't be "reconstructed data" in any sense of
the word; so I think it'd be abuse of the concept --- which would come
back to bite us if we ever try to support index-only scans with SPGiST.
ISTM what this points up is that the opclass might want some private
state kept around during a tree descent.  If we want to support that,
we should support it as a separate concept from reconstructed data.

			regards, tom lane