From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
Cc: | Gabriel Weinberg <yegg(at)alum(dot)mit(dot)edu>, "'Bruno Wolff III'" <bruno(at)wolff(dot)to>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Sequential Scan Index Bug |
Date: | 2004-04-07 19:28:38 |
Message-ID: | 26750.1081366118@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> It's possible that we could do something more intelligent than the current
> behavior for that case but I can't come up with a particularly good
> choice that wouldn't have bad effects elsewhere.
In theory we could recognize that "integer_column = 4.35" will yield a
constant false. If the expression were replaced by "false" during
constant folding then the planner would produce a short-circuited plan
that won't actually examine the table.
In practice, though, I don't see any way to do that that wouldn't be a
horrendous kluge. I don't like putting special-case type-specific
knowledge into the planner; yet here we have knowledge that's not only
type-specific but specific to the combination of two different types.
Yech. I don't see any hope for a catalog-driven, extensible approach
for such things.
You'd also have to ask questions about whether the planner time spent
testing for such cases would really be a good investment...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-04-07 19:32:21 | Re: BUG #1129: select query returns multiple results for a japanese characters |
Previous Message | Tom Lane | 2004-04-07 18:47:53 | Re: INSERT INTO ... SELECT |