Re: [HACKERS] Re: type coersion (was OR clause status)
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Re: type coersion (was OR clause status) |
Дата | |
Msg-id | 1652.902601660@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: type coersion (was OR clause status) ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>) |
Список | pgsql-hackers |
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes: > The *only case* I've noticed so far which does better in v6.3.2 than > "v6.4today" (not yet v6.4alpha :) is the one involving OIDs: > regression=> explain select * from tenk1 where oid = 3000; > Index Scan on tenk1 (cost=2.05 size=1 width=100) Actually, I'm aware of another one: comparisons using "> constant" or "< constant" seem more likely to use an index in 6.3.2 than they do in the sources I have. I have examples involving both datetime and int4 columns where "where x = constant" will be implemented by index scan, but "where x > constant" will not. Explicit casts of the righthand side make no difference. And it works fine in 6.3.2. I'm a couple of weeks behind the CVS tree, so I was going to wait until I'd confirmed it with up-to-the-minute sources before complaining. But if you're proceeding on the assumption that the "oid = integer" case is the only thing that's broken, you may be misled. The fact that casting doesn't affect this makes me think it is a different problem than the must-cast-to-get-an-index-scan cases we've discussed so far. regards, tom lane
В списке pgsql-hackers по дате отправления: