Thread: 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.
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!