From: | Robert Haas <robertmhaas(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: match_clause_to_indexcol() |
Date: | 2010-11-20 18:33:24 |
Message-ID: | AANLkTikF0AH22eoqDiiGSpiZJzmn4WWM6ga+VVRgbSYQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Nov 20, 2010 at 1:01 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I was looking at KNNGIST some more today and found myself trying to
>> disentangle what match_clause_to_indexcol() is actually doing. It
>> appears to me that the opfamily passed to that function is always the
>> same as index->opfamily[indexcol], which seems like needless
>> notational complexity. Maybe I'm missing something, but the attached
>> patch seems to make things simpler and clearer. Thoughts?
>
> +1. I think the existing coding dates from a time when we didn't have
> IndexOptInfo at all, or at least didn't pass it around to all these
> sub-functions, so there was no other path for getting at the info.
>
> But if you're going to do that, get rid of DoneMatchingIndexKeys
> altogether,
Sure. That's a giant crock.
> along with the extra zero that plancat.c adds to the
> opfamily array. We don't need to be using more than one way to
> iterate over those arrays.
I am slightly worried that this might break third-party code, or even
some part of the core code that's still using the old system. I don't
mind if you want to rip it out, but personally, I'd rather leave that
part well enough alone. Revised patch attached.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachment | Content-Type | Size |
---|---|---|
indxpath-cleanup.patch | text/x-patch | 4.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-11-20 18:37:59 | Re: match_clause_to_indexcol() |
Previous Message | Tom Lane | 2010-11-20 18:31:54 | Re: [PATCH] Custom code int(32|64) => text conversions out of performance reasons |