Re: [PERFORM] Scaling further up
On Tue, Mar 02, 2004 at 02:16:24PM -0700, scott.marlowe wrote: > It's a common misconception that faster RPM drives are a lot faster, > when, in fact, their only speed advantage is slight faster seeks. > The areal density of faster spinning hard drives tends to be > somewhat less than the slower spinning drives, since the maximum > frequency the heads can work in on both drives, assuming the same > technology, is the same. I.e. the speed at which you can read data > off of the platter doesn't usually go up with a higher RPM drive, > only the speed with which you can get to the first sector. This would imply that an upgrade in drive RPM should be accompanied by a decrease in random_page_cost, correct? random_page_cost should be set with the following things taken into account: - seek speed - likelihood of page to be cached in memory by the kernel - anything else? Sorry, i realize this pulls the thread a bit off-topic, but i've heard that about RPM speeds before, and i just want some confirmation that my deductions are reasonable. -johnnn ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PERFORM] sql performance and cache
On Sat, Oct 11, 2003 at 10:43:04AM +0100, Chris Faulkner wrote: > I have two very similar queries which I need to execute. They both > have exactly the same from / where conditions. When I execute the > first, it takes about 16 seconds. The second is executed almost > immediately after, it takes 13 seconds. In short, I'd like to know > why the query result isn't being cached and any ideas on how to > improve the execution. The way to do the type of caching you're talking about, if i understand you correctly, would be to create a temporary table. Specifically, create a temporary table with the results of the second query. Then run a select * on that table (with no where clause), and follow it with a select max(replace(...)) on the same table (no where clause). That guarantees two things: 1- The joins/filters are not parsed and evaluated twice, with the corresponding disk reads. 2- The data is exactly consistent between the two queries. Correct me if i misunderstood your problem. -johnn ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PERFORM] One or more processor ?
On Fri, Oct 10, 2003 at 12:42:04PM -0400, Bill Moran wrote: > 4) It simply isn't practical to expect a single query to >execute on multiple processors simultaneously. > > Do you know of any RDBMS that actually will execute a single query > on multiple processors? Yes, DB2 will do this if configured correctly. It's very useful for large, complicated queries that have multiple subplans. -joh ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
