Re: sinval synchronization considered harmful

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <robertmhaas(at)gmail(dot)com>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: sinval synchronization considered harmful
Date: 2011-07-21 16:16:28
Message-ID: 4E280A8C020000250003F661@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas wrote:

> SIGetDataEntries(). I believe we need to bite the bullet and
> rewrite this using a lock-free algorithm, using memory barriers on
> processors with weak memory ordering.

> [32 processors; 80 clients]

> On unpatched master

> tps = 132518.586371 (including connections establishing)
> tps = 130968.749747 (including connections establishing)
> tps = 132574.338942 (including connections establishing)

> With the lazy vxid locks patch

> tps = 119215.958372 (including connections establishing)
> tps = 113056.859871 (including connections establishing)
> tps = 160562.770998 (including connections establishing)

> gets rid of SInvalReadLock and instead gives each backend its own
> spinlock.

> tps = 167392.042393 (including connections establishing)
> tps = 171336.145020 (including connections establishing)
> tps = 170500.529303 (including connections establishing)

> SIGetDataEntries() can pretty easily be made lock-free.

> tps = 203256.701227 (including connections establishing)
> tps = 190637.957571 (including connections establishing)
> tps = 190228.617178 (including connections establishing)

> Thoughts? Comments? Ideas?

Very impressive! Those numbers definitely justify some #ifdef code
to provide alternatives for weak memory ordering machines versus
others. With the number of CPUs climbing as it is, this is very
important work!

-Kevin

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-07-21 16:17:19 Re: Single pass vacuum - take 1
Previous Message Merlin Moncure 2011-07-21 16:11:36 Re: fixing PQsetvalue()