From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Some interesting results from tweaking spinlocks |
Date: | 2002-01-05 04:49:06 |
Message-ID: | 9837.1010206146@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> The difference is small, perhaps 15%.
The thing that gets my attention is not that it's so small, it's that
it is so large. My expectation was that that code would hardly ever
be executed at all, and even less seldom (on a multiprocessor) need to
block via select(). How is it that *increasing* the delay interval
(which one might reasonably expect to simply waste cycles) can achieve
a 15% improvement in total throughput? That shouldn't be happening.
> My feeling is that we may want to start configuring whether we are on
> a multi-cpu machine and handle thing differently.
That would be more palatable if there were some portable way of
detecting it. But maybe we'll be forced into an "is_smp" GUC switch.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-01-05 04:52:06 | Re: Some interesting results from tweaking spinlocks |
Previous Message | Bruce Momjian | 2002-01-05 04:34:43 | Re: Some interesting results from tweaking spinlocks |