Re: [HACKERS] indexes and floats
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] indexes and floats |
Дата | |
Msg-id | 35CA8B91.8AF7114A@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] indexes and floats (dg@informix.com (David Gould)) |
Ответы |
Re: [HACKERS] indexes and floats
|
Список | 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
В списке pgsql-hackers по дате отправления: