Re: [HACKERS] indexes and floats

> David Gould wrote:
> >
> > > ^^^^^^^^^
> > > I don't like the idea to evaluate random() in WHERE x = random()
> > > for _each_ tuple. The same for WHERE insert_date = now() - 5
> > > /* 5 days */. Imho, these functions should be evaluated ONCE
> > > by executor, but EACH time when executor starts. There is big
> > > difference between evaluation in parser/planner and in executor
> > > due to ability (currently, very limitted) to have prepared plans
> > > (parsed/planned). And nothing more. Imho, queries must return
> > > consistent set of data: if I want to get rows inserted 5 days
> > > ago and run query with WHERE insert_date = now() - 5 near 12PM
> > > then I risk to get inconsistent set of rows if now() will be
> > > evaluated for EACH tuple.
> >
> > Perhaps random was a bad example, the point I was trying to make was that
> > it is a function that is not wholely determined by its arguments.
> >
> > However, I disagree with your contention about random() and now() also.
> > Think about the statement
> >
> > insert into samples
> > select random(), xval, yval from points;
> >
> > The intent being to associate a random value with each of the x,y pairs...
>
> Imho, we have to treat random() etc differently in target list and
> qual! WHERE defines set of rows to be returned by query, functions
> in target list define representation of this set.
>
> >
> > > > Also, perhaps instead of doing constant folding in the parser, consider makeing
> > > > it part of rewrite. This pass would just traverse the tree looking for
> > > > functions with constant arguements and would pre-evaluate them and and
> > > > save the result in the wherever the cacheable results would be stored. No
> > > > special case required except that the optimizer would have to notice that
> > > > a pre-computed result was available to use as a key value.
> > >
> > > This is bad for performance.
> >
> > What_ is the "This" that is bad for performance? It is not clear what you
> > mean here.
> >
> > Do you mean memoizing? If so, I strongly disagree, and there is a ton of
> > work on this that supports me.
> >
> > Or do you mean adding the cacheable function optimization to rewrite? If so,
> ^^^^^^^^^^
> This. Why should we traverse the tree once more time?
> What the problem to let parser handle these functions?
>
> > why is this a problem? I am assuming that this can be piggybacked on one
> > of the existing expression tree traversals, so I just don't see how
> > this creates more work than doing it in the parser.

Yep. Rewrite already is confusing. Parser has this type of handling in
there already.

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)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)