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 <alvherre@dcc.uchile.cl>)
Ответы Re: Joel's Performance Issues WAS : Opteron vs Xeon  ("Jim C. Nasby" <decibel@decibel.org>)
Список 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
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 по дате отправления:

Предыдущее
От: Mischa Sandberg
Дата:
Сообщение: Re: Joel's Performance Issues WAS : Opteron vs Xeon
Следующее
От: "Anjan Dave"
Дата:
Сообщение: Updating table, precautions?