Anyone see a need for BTItem/HashItem?
I'm considering getting rid of the BTItem/BTItemData and
HashItem/HashItemData struct definitions and just referencing
IndexTuple(Data) directly in the btree and hash AMs. It appears that
at one time in the forgotten past, there was some access-method-specific
data in index entries in addition to the common IndexTuple struct, but
that's been gone for a long time and I can't see a reason why either of
these AMs would resurrect it. So this just seems like extra notational
cruft to me, as well as an extra layer of palloc overhead (see eg
_bt_formitem()). GIST already got rid of this concept, or never had it.
Does anyone see a reason to keep this layer of struct definitions?
regards, tom lane
On Mon, Jan 16, 2006 at 03:52:01PM -0500, Tom Lane wrote:
I'm considering getting rid of the BTItem/BTItemData and
HashItem/HashItemData struct definitions and just referencing
IndexTuple(Data) directly in the btree and hash AMs. It appears
that at one time in the forgotten past, there was some
access-method-specific data in index entries in addition to the
common IndexTuple struct, but that's been gone for a long time and I
can't see a reason why either of these AMs would resurrect it. So
this just seems like extra notational cruft to me, as well as an
extra layer of palloc overhead (see eg _bt_formitem()). GIST
already got rid of this concept, or never had it.Does anyone see a reason to keep this layer of struct definitions?
If you cut it out, what will the "heap" and "index" access methods
needed for SQL/MED use?
Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 415 235 3778
Remember to vote!
David Fetter <david@fetter.org> writes:
On Mon, Jan 16, 2006 at 03:52:01PM -0500, Tom Lane wrote:
Does anyone see a reason to keep this layer of struct definitions?
If you cut it out, what will the "heap" and "index" access methods
needed for SQL/MED use?
What's that have to do with this?
regards, tom lane
From what I've seen, I don't think we need to keep them around.
Show quoted text
On 1/16/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I'm considering getting rid of the BTItem/BTItemData and
HashItem/HashItemData struct definitions and just referencing
IndexTuple(Data) directly in the btree and hash AMs. It appears that
at one time in the forgotten past, there was some access-method-specific
data in index entries in addition to the common IndexTuple struct, but
that's been gone for a long time and I can't see a reason why either of
these AMs would resurrect it. So this just seems like extra notational
cruft to me, as well as an extra layer of palloc overhead (see eg
_bt_formitem()). GIST already got rid of this concept, or never had it.Does anyone see a reason to keep this layer of struct definitions?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
On Mon, Jan 16, 2006 at 04:02:07PM -0500, Tom Lane wrote:
David Fetter <david@fetter.org> writes:
On Mon, Jan 16, 2006 at 03:52:01PM -0500, Tom Lane wrote:
Does anyone see a reason to keep this layer of struct
definitions?If you cut it out, what will the "heap" and "index" access methods
needed for SQL/MED use?What's that have to do with this?
I'm sure you'll correct me if I'm mistaken, but this is a candidate
for the spot where such interfaces--think of Informix's Virtual
(Table|Index) Interface--would go.
Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 415 235 3778
Remember to vote!
David Fetter <david@fetter.org> writes:
On Mon, Jan 16, 2006 at 04:02:07PM -0500, Tom Lane wrote:
David Fetter <david@fetter.org> writes:
If you cut it out, what will the "heap" and "index" access methods
needed for SQL/MED use?What's that have to do with this?
I'm sure you'll correct me if I'm mistaken, but this is a candidate
for the spot where such interfaces--think of Informix's Virtual
(Table|Index) Interface--would go.
Can't imagine putting anything related to external-database access
inside either the btree or hash AMs; it'd only make sense to handle
it at higher levels. It's barely conceivable that external access
would make sense as a specialized AM in its own right, but I don't
see managing external links exclusively within the indexes.
IOW, if we did need extra stuff in IndexTuples for external access,
we'd want to put it inside IndexTuple, not in a place where it could
only be seen by these AMs.
regards, tom lane
On Mon, Jan 16, 2006 at 04:21:50PM -0500, Tom Lane wrote:
David Fetter <david@fetter.org> writes:
On Mon, Jan 16, 2006 at 04:02:07PM -0500, Tom Lane wrote:
David Fetter <david@fetter.org> writes:
If you cut it out, what will the "heap" and "index" access
methods needed for SQL/MED use?What's that have to do with this?
I'm sure you'll correct me if I'm mistaken, but this is a
candidate for the spot where such interfaces--think of Informix's
Virtual (Table|Index) Interface--would go.Can't imagine putting anything related to external-database access
inside either the btree or hash AMs; it'd only make sense to handle
it at higher levels. It's barely conceivable that external access
would make sense as a specialized AM in its own right, but I don't
see managing external links exclusively within the indexes.IOW, if we did need extra stuff in IndexTuples for external access,
we'd want to put it inside IndexTuple, not in a place where it could
only be seen by these AMs.
Thanks for the explanation :)
Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 415 235 3778
Remember to vote!