| |||||||||||||
|
| |||||||||||||
Haas: Big ideas [for PostgreSQL]Haas: Big ideas [for PostgreSQL]Posted May 6, 2010 21:02 UTC (Thu) by nevyn (subscriber, #33129)In reply to: Haas: Big ideas [for PostgreSQL] by endecotp Parent article: Haas: Big ideas [for PostgreSQL]
That seems reasonable, as you'd actually need an index on age(mydate) ... or the optimizer would need to know that even though age(mydate) gives different results each time they are always directly related to mydate (so if mydate1 > Y and mydate2 > Y, then if age(mydate1) > Z it can be inferred age(mydate2) > Z). This seems hard though (but I'm not a PSQL developer :).
I'm also assuming that current_date is fixed for the SELECT/transaction ... but that might not be true either, in which case it's impossible to optimize.
(Log in to post comments)
Haas: Big ideas [for PostgreSQL] Posted May 10, 2010 16:07 UTC (Mon) by intgr (subscriber, #39733) [Link]
> as you'd actually need an index on age(mydate)
Obviously you can't do that, because the age() function is not stable -- its output changes every microsecond.
Heck, I didn't even know that there's an age() function. I always did it the old fasioned way: where some_timestamp > now() - interval '1 day'
|
|
||||||||||||