Re: lazy vxid locks, v1

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: lazy vxid locks, v1
Дата
Msg-id 4DF6C2C3.8080303@2ndQuadrant.com
обсуждение исходный текст
Ответ на Re: lazy vxid locks, v1  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
Список pgsql-hackers
On 06/13/2011 07:55 AM, Stefan Kaltenbrunner wrote:
> all those tests are done with pgbench running on the same box - which
> has a noticable impact on the results because pgbench is using ~1 core
> per 8 cores of the backend tested in cpu resoures - though I don't think
> it causes any changes in the results that would show the performance
> behaviour in a different light.
>    

Yeah, this used to make a much bigger difference, but nowadays it's not 
so important.  So long as you have enough cores that you can spare a 
chunk of them to drive the test with, and you crank "-j" up to a lot, 
there doesn't seem to be much of an advantage to moving the clients to a 
remote system now.  You end up trading off CPU time for everything going 
through the network stack, which adds yet another set of uncertainty to 
the whole thing anyway.

I'm glad to see so many people have jumped onto doing these SELECT-only 
tests now.  The performance farm idea I've been working on runs a test 
just like what's proven useful here.  I'd suggested that because it's 
been really sensitive to changes in locking and buffer management for me.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: creating CHECK constraints as NOT VALID
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_trgm: unicode string not working