| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nils Goroll | 2012-07-02 17:19:18 | away soon - spinlock->pthread_mutex : first results with Jeff's pgbench+plsql |
| Previous Message | Robert Haas | 2012-07-02 17:03:15 | Re: Checkpointer on hot standby runs without looking checkpoint_segments |