Skip site navigation (1) Skip section navigation (2)

Re: spinlock->pthread_mutex : first results with Jeff's pgbench+plsql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Nils Goroll <slink(at)schokola(dot)de>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: spinlock->pthread_mutex : first results with Jeff's pgbench+plsql
Date: 2012-07-02 17:13:55
Message-ID: 19536.1341249235@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> The delay code is stupider than it could be, in that it sleeps without
> regard to what's happening elsewhere in the system.  The futex stuff
> was interesting to me because it potentially provides a way to sleep
> "until something interesting happens" rather than "for a fixed amount
> of time".  But it's unclear to me what exactly we'd have to do to
> squeeze out a win, or even whether it's possible.

Right.  AFAICS, sleeping "until something happens" necessarily requires
adding overhead on the other side, ie, lock releasers will have to do
something extra to wake up sleepers.  If that means adding overhead
to low-contention cases, we could come out behind even if it improves
high-contention cases.  Tradeoffs, always tradeoffs ...

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Nils GorollDate: 2012-07-02 17:19:18
Subject: away soon - spinlock->pthread_mutex : first results with Jeff's pgbench+plsql
Previous:From: Robert HaasDate: 2012-07-02 17:03:15
Subject: Re: Checkpointer on hot standby runs without looking checkpoint_segments

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group