| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
| Cc: | PostgreSQL-development <hackers(at)postgreSQL(dot)org> |
| Subject: | Re: [HACKERS] Re: type coersion (was OR clause status) |
| Date: | 1998-08-08 18:41:00 |
| Message-ID: | 1652.902601660@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Thomas G. Lockhart" <lockhart(at)alumni(dot)caltech(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 1998-08-08 19:16:51 | Re: [HACKERS] Re: type coersion (was OR clause status) |
| Previous Message | Tom Lane | 1998-08-08 18:30:37 | Re: [HACKERS] thread-safe libpq and DBD::Pg |