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
