From: | "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Anyone see a need for BTItem/HashItem? |
Date: | 2006-01-16 21:02:37 |
Message-ID: | 36e682920601161302v338bf4ara63ac292e1825cdf@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
From what I've seen, I don't think we need to keep them around.
On 1/16/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-01-16 21:04:58 | Re: [HACKERS] message for constraint |
Previous Message | Tom Lane | 2006-01-16 21:02:07 | Re: Anyone see a need for BTItem/HashItem? |