From: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Vadim Mikheev <vadim(at)krs(dot)ru> |
Cc: | David Gould <dg(at)informix(dot)com>, Brook Milligan <brook(at)trillium(dot)NMSU(dot)Edu>, maillist(at)candle(dot)pha(dot)pa(dot)us, tgl(at)sss(dot)pgh(dot)pa(dot)us, hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] indexes and floats |
Date: | 1998-08-07 05:07:29 |
Message-ID: | 35CA8B91.8AF7114A@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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.
This is perhaps a bad example, because now() (and 'now') return the
transaction time, guaranteed to be the same for each row evaluation of a
query, and the same for every query within a transaction.
What should be behavior of
update x set i = random();
be? I would have assumed that random() is evaluated once; are there any
truely volatile functions in SQL92?
> > Also, perhaps instead of doing constant folding in the parser,
> > consider making 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 makes this bad for performance? An extra traversal of the parse
tree? Or something else??
- Tom
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1998-08-07 05:10:18 | OR clause and joins |
Previous Message | Bruce Momjian | 1998-08-07 05:03:42 | Re: [HACKERS] indexes and floats |