On 29.07.2012 00:50, Tom Lane wrote:
> 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.
I can see that for leaf nodes, but does that also hold for inner nodes?
> 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.
Yeah, that seems better. The representation of an inner node is
datatype-specific, there should be no need to expose "reconstructed"
inner node values outside a datatype's SP-GiST implementation.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
