FAQ
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.

Search Discussions

  • Tom Lane at Jun 9, 2006 at 4:31 pm

    Sven Geisler 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
  • Sven Geisler at Jul 3, 2006 at 12:41 pm
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJun 9, '06 at 4:31p
activeJul 3, '06 at 12:41p
posts3
users2
websitepostgresql.org...
irc#postgresql

2 users in discussion

Sven Geisler: 2 posts Tom Lane: 1 post

People

Translate

site design / logo © 2022 Grokbase