| From: | Russell Smith <mr-russ(at)pws(dot)com(dot)au> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Hardware upgrade for a high-traffic database |
| Date: | 2004-08-11 23:52:20 |
| Message-ID: | 200408120952.20352.mr-russ@pws.com.au |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rudi Starcevic | 2004-08-12 00:00:02 | Buld Insert and Index use. |
| Previous Message | Russell Smith | 2004-08-11 23:44:56 | Re: Storing binary data. |