Re: Joel's Performance Issues WAS : Opteron vs Xeon

From: Joel Fradkin
Subject: Re: Joel's Performance Issues WAS : Opteron vs Xeon
Date: ,
Msg-id: 000001c5477e$da38e3e0$797ba8c0@jfradkin
(view: Whole thread, Raw)
In response to: Re: Joel's Performance Issues WAS : Opteron vs Xeon  (Alvaro Herrera)
Responses: Re: Joel's Performance Issues WAS : Opteron vs Xeon  ("Jim C. Nasby")
List: pgsql-performance

One further question is: is this really a meaningful test?  I mean, in
production are you going to query 300000 rows regularly?

It is a query snippet if you will as the view I posted for audit and case
where tables are joined are more likely to be ran.

Josh and I worked over this until we got explain analyze on the linux box to
1 sec. I was just using this as a test as I don't have my views set up on

So many of my reports pull huge data sets (comprised of normalized joins).
I am thinking I probably have to modify to using an non normalized table,
and Josh is sending me information on using cursors instead of selects.

And is the system always going to be used by only one user?
No we have 400+ concurrent users

I guess the question is if this big select is representative of the load you
expect in production.
Yes we see many time on the two processor box running MSSQL large return
sets using 100%cpu for 5-30 seconds.

What happens if you execute the query more times?  Do the times stay the
same as the second run?
I will definitely have to pressure testing prior to going live in
production. I have not done concurrent tests as honestly single user tests
are failing, so multiple user testing is not something I need yet.


Alvaro Herrera (<alvherre[@]>)
"Use it up, wear it out, make it do, or do without"

pgsql-performance by date:

From: "Jim C. Nasby"
Subject: Re: Sort and index
From: "Jim C. Nasby"
Subject: Interesting numbers on a CREATE INDEX