Обсуждение: 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

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!