Re: [HACKERS] OR clause status

Поиск
Список
Период
Сортировка
От Thomas G. Lockhart
Тема Re: [HACKERS] OR clause status
Дата
Msg-id 35C9489B.781E162@alumni.caltech.edu
обсуждение исходный текст
Ответ на Re: [HACKERS] OR clause status  (Bruce Momjian <maillist@candle.pha.pa.us>)
Ответы Re: [HACKERS] OR clause status
Список pgsql-hackers
> > I think the OID auto-casting should be very easy
> > Once the development tree becomes unbroken...
> Yes, I think there are some very good reasons to evaluate functions on
> constants inside the parser.

I wasn't actually suggesting making real changes to the parser. I
_think_ I can get the OID vs int4 coersion problem fixed with a one-line
change to a header file, but need a working tree to do it :(

Any progress on getting the tree to compile? Are there some people who
don't see a problem??

> There are some operations that look at
> index selectivity that need to know the constant value, rather than
> knowing if the function returns an int.  For example x > 3 looks at
> the pg_statistics table to see max/min values.
>
> You certainly don't want to be evaluating functions on constants
> inside the optimizer.

?? Why not? It is an optimization after all. I have never looked at the
optimizer code however. Are you saying that the current optimizer
doesn't have a pass or phase where functions could be evaluated? Should
we add a pass to do this? I've been a bit worried about coding too many
optimizations into the parser, since they might become pretty obscure
buried in there.

                        - Tom

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Large objects names
Следующее
От: Peter T Mount
Дата:
Сообщение: Re: [HACKERS] CVS and the backend