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 по дате отправления: