patch postgresql for AMD64 (Opteron)
Hi all,
I created a patch for PostgreSQL and x86 architecture.
This patch address a Opteron-specific
behavior regarding some assembler statements.
The patch based on a patch to PostgreSQL 8.0.3 which was worked out by
RedHat.
Tom did change src/include/storage/s_lock.h for PostgreSQL 8.1.x. This
change is only for x86_64. I need to compile PostgreSQL 8.1.4 for 32-bit
on a Opteron. The reason for the 32-bit binary is a failover/test box
with XEONs which didn't know anything about EM64T.
Anyhow, I change the i386 part of s_lock.h too.
BTW: Tom did a great job on BufMgrLock. The original patch for pg 8.0
did push the performance with many parallel queries on another level.
We did run internal benchmarks and the patch version was 2.5 times
faster. The benefit of this change to Pg 8.1.4 is much smaller. I did a
test with pg_bench and the benefit is at around 10 percent.
This change was tested on Opteron, XEON MP w/o EM64T and XEON DP without
any issues.
Cheers
Sven.
Attachments:
postgresql-8.1.4.patchtext/plain; name=postgresql-8.1.4.patchDownload+2-5
Sven Geisler <sgeisler@aeccom.com> writes:
I created a patch for PostgreSQL and x86 architecture.
This patch address a Opteron-specific
behavior regarding some assembler statements.
AFAICT this patch essentially proposes that we should allow the single
case of an Opteron running in 32-bit mode to determine our optimization
strategy for all 32-bit Intel. Tail wagging dog, no?
As the comment notes, it's not real clear that the separate cmpb is a
win on average, but this case is not the average case I'm interested in.
If you want to make an argument for removing the cmpb you need to
provide numbers on mainstream 32-bit platforms.
regards, tom lane
Hi Tom,
I remember that you provide a small SQL script to force the context
switch storm. Can you provide a similar script for Pg 8.1.4?
It looks to me that you get context switch storm if you access with
SELECT one table from multiple clients.
I have a customer which has an current XEON MP DualCore and we get
150000+ context switches/sec. We have around 30 clients. We use RHEL 4
in 32-bit (i368) mode. I didn't use the patch for the Opteron-specific
behavior.
Cheers
Sven.
Tom Lane schrieb:
Sven Geisler <sgeisler@aeccom.com> writes:
I created a patch for PostgreSQL and x86 architecture.
This patch address a Opteron-specific
behavior regarding some assembler statements.AFAICT this patch essentially proposes that we should allow the single
case of an Opteron running in 32-bit mode to determine our optimization
strategy for all 32-bit Intel. Tail wagging dog, no?As the comment notes, it's not real clear that the separate cmpb is a
win on average, but this case is not the average case I'm interested in.
If you want to make an argument for removing the cmpb you need to
provide numbers on mainstream 32-bit platforms.regards, tom lane
--
/This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you are not the intended recipient, you should not
copy it, re-transmit it, use it or disclose its contents, but should
return it to the sender immediately and delete your copy from your
system. Thank you for your cooperation./
Sven Geisler <sgeisler@aeccom.com> Tel +49.30.5362.1627 Fax .1638
Senior Developer, AEC/communications GmbH Berlin, Germany