Re: best way to fetch next/prev record based on index
От | Tom Lane |
---|---|
Тема | Re: best way to fetch next/prev record based on index |
Дата | |
Msg-id | 23584.1091033781@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: best way to fetch next/prev record based on index (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: best way to fetch next/prev record based on index
(Greg Stark <gsstark@mit.edu>)
|
Список | pgsql-performance |
Greg Stark <gsstark@mit.edu> writes: > Tom Lane <tgl@sss.pgh.pa.us> writes: >> The only reason the code in parse_expr.c appears new is that the >> functionality used to be in gram.y. > Ah, that was what I was missing. Though it's odd since it seems there was code > in parse_expr.c to handle the "=" case specially. IIRC, the case involving a subselect, eg ... WHERE (1,2) = ANY (SELECT a, b FROM foo) ... has always been handled in parse_expr.c, but cases involving simple rows were previously expanded in gram.y. One of the reasons I moved the logic over to parse_expr.c was the thought that it would be easier to do it right in parse_expr.c --- gram.y would not be allowed to look up related operators, which seems necessary to handle the construct per spec. > I tried my hand at this last night and think I did an ok first pass. The main issue in my mind is whether to invent a separate node type for row comparisons. This is probably a good idea for a number of reasons, the most obvious being that there's no way to avoid multiple evaluations of the subexpressions if you try to expand it into simple comparisons. Also it seems likely that the planner would find it easier to recognize the relationship to a multicolumn index than if the thing is expanded. (But teaching the planner and the index mechanisms themselves about this is going to be a major project in any case.) One thing I did not like about your first pass is that it makes unsupportable assumptions about there being a semantic relationship between operators named, say, '<' and '<='. Postgres used to have such bogosity in a number of places but we've managed to get rid of most of it. (Offhand I think the only remaining hard-wired assumption about operators of particular names having particular semantics is that the foreign key mechanisms assume '=' must be the right operator to compare keys with. Eventually we need to get rid of that too.) IMHO the right way to do this is to look up a suitable btree operator class and use the appropriate member operators of that class. (In a separate-node-type implementation, we'd probably ignore the operators as such altogether, and just call the btree comparison function of the opclass.) It's not entirely clear to me how to select the opclass when the initially given inputs are of different types, though. In the present code we leave it to oper() to do the right thing, including possibly coercing the inputs to matching types. Possibly we should still apply oper(), but then insist that the selected operator appear as a btree opclass member, comparable to the way we handle sort operators now. regards, tom lane
В списке pgsql-performance по дате отправления: