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

От: Joel Fradkin
Тема: Re: Joel's Performance Issues WAS : Opteron vs Xeon
Дата: ,
Msg-id: 000001c5477e$da38e3e0$797ba8c0@jfradkin
(см: обсуждение, исходный текст)
Ответ на: Re: Joel's Performance Issues WAS : Opteron vs Xeon  (Alvaro Herrera)
Ответы: Re: Joel's Performance Issues WAS : Opteron vs Xeon  ("Jim C. Nasby")
Список: pgsql-performance

Скрыть дерево обсуждения

Re: Joel's Performance Issues WAS : Opteron vs Xeon  ("Dave Page", )
 Re: Joel's Performance Issues WAS : Opteron vs Xeon  (Andreas Pflug, )
  Re: Joel's Performance Issues WAS : Opteron vs Xeon  ("Joel Fradkin", )
   Re: Joel's Performance Issues WAS : Opteron vs Xeon  (Bruce Momjian, )
   Re: Joel's Performance Issues WAS : Opteron vs Xeon  (Alvaro Herrera, )
    Re: Joel's Performance Issues WAS : Opteron vs Xeon  (Mischa Sandberg, )
    Re: Joel's Performance Issues WAS : Opteron vs Xeon  ("Joel Fradkin", )
     Re: Joel's Performance Issues WAS : Opteron vs Xeon  ("Jim C. Nasby", )
      Re: Joel's Performance Issues WAS : Opteron vs Xeon  ("Joel Fradkin", )
       Re: Joel's Performance Issues WAS : Opteron vs Xeon  ("Joshua D. Drake", )
        Re: Joel's Performance Issues WAS : Opteron vs Xeon  (, )
      Re: Joel's Performance Issues WAS : Opteron vs Xeon  (Christopher Browne, )

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
MYSQL.

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.

Joel

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



В списке pgsql-performance по дате сообщения:

От: "Jim C. Nasby"
Дата:
Сообщение: Re: Sort and index
От: "Jim C. Nasby"
Дата:
Сообщение: Interesting numbers on a CREATE INDEX