Re: match_clause_to_indexcol()
От | Robert Haas |
---|---|
Тема | Re: match_clause_to_indexcol() |
Дата | |
Msg-id | AANLkTikF0AH22eoqDiiGSpiZJzmn4WWM6ga+VVRgbSYQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: match_clause_to_indexcol() (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: match_clause_to_indexcol()
|
Список | pgsql-hackers |
On Sat, Nov 20, 2010 at 1:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.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
Вложения
В списке pgsql-hackers по дате отправления: