Re: [HACKERS] indexes and floats
От | Vadim Mikheev |
---|---|
Тема | Re: [HACKERS] indexes and floats |
Дата | |
Msg-id | 35CA8CE2.BC2EBE8B@krs.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] indexes and floats (dg@informix.com (David Gould)) |
Список | pgsql-hackers |
Thomas G. Lockhart wrote: > > > 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. yes, this is bad example -:) > > What should be behavior of > > update x set i = random(); > > be? I would have assumed that random() is evaluated once; are there any I don't know. I mostly concern about WHERE just because of this defines data set to be returned by query. > truely volatile functions in SQL92? This is what I also would like to know. > > > > 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 ^^^^^^^^^^^^^^^ This. I don't see any reasons for this. > tree? Or something else?? Vadim
В списке pgsql-hackers по дате отправления: