Re: Hardware upgrade for a high-traffic database
От | Russell Smith |
---|---|
Тема | Re: Hardware upgrade for a high-traffic database |
Дата | |
Msg-id | 200408120952.20352.mr-russ@pws.com.au обсуждение исходный текст |
Ответ на | Re: Hardware upgrade for a high-traffic database ("Jason Coene" <jcoene@gotfrag.com>) |
Список | pgsql-performance |
[snip] > > One question I do have though - you specifically mentioned NOW() as > something to watch out for, in that it's mutable. We typically use COUNT() > as a subselect to retrieve the number of associated rows to the current > query. Additionally, we use NOW a lot, primarily to detect the status of a > date, i.e.: > > SELECT id FROM subscriptions WHERE userid = 11111 AND timeend > NOW(); > > Is there a better way to do this? I was under the impression that NOW() was > pretty harmless, just to return a current timestamp. > NOW() will trigger unnessecary sequence scans. As it is unknown with prepared query and function when the statement is run, the planner plans the query with now as a variable. This can push the planner to a seq scan over and index scan. I have seen this time and time again. You can create your own immutable now, but don't use it in functions or prepared queries or you will get wrong results. > Based on feedback, I'm looking at a minor upgrade of our RAID controller to > a 3ware 9000 series (SATA with cache, battery backup optional), and > re-configuring it for RAID 10. It's a damn cheap upgrade at around $350 and > an hour of downtime, so I figure that it's worth it for us to give it a > shot. > > Thanks, > > Jason Russell Smith
В списке pgsql-performance по дате отправления: