From: | Vadim Mikheev <vadim(at)krs(dot)ru> |
---|---|
To: | David Gould <dg(at)informix(dot)com> |
Cc: | Brook Milligan <brook(at)trillium(dot)NMSU(dot)Edu>, maillist(at)candle(dot)pha(dot)pa(dot)us, lockhart(at)alumni(dot)caltech(dot)edu, tgl(at)sss(dot)pgh(dot)pa(dot)us, hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] indexes and floats |
Date: | 1998-08-07 02:45:02 |
Message-ID: | 35CA6A2E.B33523BA@krs.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Gould wrote:
>
> >
> > Wouldn't the concept of VOLATILE be relevant here (ala the same
> > keyword in C and C++)? In those languages the keyword influences the
> > nature of optimizations that can be done, which seems to be the
> > problems involved here. We could have a function bool
> > pg_proc.is_volatile() to determine whether or not the result of the
> > function call can be determined from its arguments. If so and the
> > arguments are constants, the function could be evaluated once in the
> > parser; otherwise, it would need to be evaluated for each tuple.
^^^^^^^^^^^^^^
> In Illustra this is called "variant". A variant function (eg random()) must
> be evaluated each time. A nonvariant function can have it's result cached
^^^^^^^^^
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.
> 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.
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 1998-08-07 02:55:30 | Re: [HACKERS] CVS and the backend |
Previous Message | David Gould | 1998-08-07 00:00:32 | Re: [HACKERS] indexes and floats |