Heikki Linnakangas <heikki.linnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers