Just started a blog session on my findings running Postgres 8.3(beta)
on a mid range Sun Fire server. Second entry is about the time lost
on LWLock handling. When concurrency increases you can see the
ProcArrayLock wait queue to start and explode.
http://blogs.sun.com/paulvandenbogaard/entry/
leight_weight_lock_contention
I will add more posts on all the other LWlock findings and the
instrumentation method being used. Unfortunately a high priority
project popped up I need to focus on. So please be patient. Hope to
finish this in the first week of april.
Thanks,
Paul
On 13-mrt-2008, at 16:56, Tom Lane wrote:
Mark Mielke <[EMAIL PROTECTED]> writes:
Alvaro Herrera wrote:
How about this wording:
"Review Simon's claims to improve performance
What sort of evidence is usually compelling? It seems to me that this
sort of change only benefits configurations with dozens or more
CPUs/cores?
The main point in my mind was that that analysis was based on the code
as it then stood. Florian's work to reduce ProcArrayLock contention
might have invalidated some or all of the ideas. So it needs a fresh
look.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
------------------------------------------------------------------------
---------------------
Paul van den Bogaard
[EMAIL PROTECTED]
ISV-E -- ISV Engineering, Opensource Engineering group
Sun Microsystems, Inc phone: +31
334 515 918
Saturnus 1
extentsion: x (70)15918
3824 ME Amersfoort mobile: +31
651 913 354
The Netherlands
fax: +31 334 515 001
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
