> The problem appears to be that the optimizer/executor does not know how
> to evaluate the constant string once-only, and insists on doing a
> sequential scan for some reason. Not really in the parser's hands.
> Remember, the types are all set and the functions are all defined by the
> time the actual optimizer/executor sees anything. There may be a slight
> bit of "optimization" which happens in the parser, but only to shoehorn
> SQL92 into the Postgres backend. Oh, there are some heuristics in the
> parser to fudge the distinctions between char/varchar/text types to
> allow reuse of some of the support code, but that is a Bad Thing in
> principle.
>
> The downside to putting more heuristics into the parser (as opposed to
> upgrading the optimizer/executor to handle the case) is that it embeds
> more assumptions about the _behavior_ of, for example, int4->float8
> conversions and would reduce the flexibility of the extensible type
> system.
>
> istm that we should be focusing on Vadim's hints on what it would take
> to use indices with function calls on constants...
I understand the problem now. There is code in the optimizer to handle
functions on constants, but it does not appear to be in a place where
index matching can use it.
I will be looking over the code in the next few weeks, but not sure if I
can figure it all out by then. I have added it to my personal TODO
list.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
