From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | josh(at)agliodbs(dot)com |
Cc: | pgsql-performance(at)postgresql(dot)org, Manfred Spraul <manfred(at)colorfullife(dot)com>, neilc(at)samurai(dot)com, markw(at)osdl(dot)org |
Subject: | Re: futex results with dbt-3 |
Date: | 2004-10-19 22:39:48 |
Message-ID: | 27697.1098225588@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> The bigger problem here is that the SMP locking bottlenecks we are
>> currently seeing are *hardware* issues (AFAICT anyway).
> Well, initial results from Gavin/Neil's patch seem to indicate that, while
> futexes do not cure the CSStorm bug, they do lessen its effects in terms of
> real performance loss.
It would be reasonable to expect that futexes would have a somewhat more
efficient code path in the case where you have to block (mainly because
SysV semaphores have such a heavyweight API, much more complex than we
really need). However, the code path that is killing us is the one
where you *don't* actually need to block. If we had a proper fix for
the problem then the context swap storm itself would go away, and
whatever advantage you might be able to measure now for futexes likewise
would go away.
In other words, I'm not real excited about a wholesale replacement of
code in order to speed up a code path that I don't want to be taking
in the first place; especially not if that replacement puts a fence
between me and working on the code path that I do care about.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Russell Smith | 2004-10-19 23:18:57 | Re: Select with qualified join condition / Batch inserts |
Previous Message | Josh Close | 2004-10-19 22:31:59 | how much mem to give postgres? |