Re: Expression indexes and casts
От | Stephan Szabo |
---|---|
Тема | Re: Expression indexes and casts |
Дата | |
Msg-id | 20040309085426.C611@megazone.bigpanda.com обсуждение исходный текст |
Ответ на | Re: Expression indexes and casts (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Expression indexes and casts
|
Список | pgsql-general |
On Tue, 9 Mar 2004, Tom Lane wrote: > Stephan Szabo <sszabo@megazone.bigpanda.com> writes: > > I haven't done any looking around yet (about to head off to work), but it > > looks like in the case where the system decides to cast a to text in order > > to get a working equality, the index isn't used, whereas in the case where > > I explicitly cast it, it can. > > I think the problem is that explicit and implicit casts are marked > differently in the cast parse node, causing equal() to consider the two > expressions different. > > There is currently a hack involving a "don't care" setting for this > field, but it doesn't help you. I wonder if it would be better to make > equal() explicitly ignore the cast-type field. It seems like that could > break other things though :-(. > > A narrower patch would be to change the cast type field to don't-care in > the copy of the parse tree that is made for planner user. > > [ thinks some more... ] On the other hand, there are cases where > explicit and implicit casting are actually semantically different (think > varchar() and char() length constraints). Maybe the don't-care business > is itself a bug, and you're just stuck. Is it possible to make an index on the implicitly cast version (or what would that take - I'm not sure how to syntactically note that in any case)? I don't really care about the explicit cast case actually.
В списке pgsql-general по дате отправления: