Re: [HACKERS] Re : Solaris Performance - 64 bit puzzle - Mailing list pgsql-general

From Bruce Momjian
Subject Re: [HACKERS] Re : Solaris Performance - 64 bit puzzle
Date
Msg-id 200205280100.g4S10hv23955@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] Re : Solaris Performance - 64 bit puzzle  (Andrew Sullivan <andrew@libertyrms.info>)
Responses Re: [HACKERS] Re : Solaris Performance - 64 bit puzzle  (Neil Conway <nconway@klamath.dyndns.org>)
Re: [HACKERS] Re : Solaris Performance - 64 bit puzzle  (Andrew Sullivan <andrew@libertyrms.info>)
List pgsql-general
TODO updated:

    Add BSD-licensed qsort() for 32-bit Solaris

---------------------------------------------------------------------------

Andrew Sullivan wrote:
> On Tue, Apr 30, 2002 at 03:28:13PM -0400, Tom Lane wrote:
>
> > Do you need to profile it?  It seemed that the 32-bit behavior for
> > many-equal-keys was so bad that it'd be easy to tell whether it's
> > fixed, just by rough overall timing of a test case...
>
> Sorry for taking yet again so long.  Fitting in little tests of this
> sort of thing can be a bit of a bear -- there's always about 50 other
> things to do.  Anyway, I've performed some simple timed tests that, I
> think, confirm that the 64 bit library on Solaris is not so bad.
>
>                              version
> -----------------------------------------------------------------
>  PostgreSQL 7.2.1 on sparc-sun-solaris2.7, compiled by GCC 3.0.3
>
> bin$ file postmaster
> postmaster:     ELF 64-bit MSB executable SPARCV9 Version 1,
> dynamically linked, not stripped
>
> The config file is the default
>
> I _think_ I've captured the case that was problematic.  As I
> understood it, qsort was having trouble when hit with many equal
> keys.  I created this table:
>
> CREATE TABLE table1 (_date_stamp timestamp default current_timestamp,
> foo text);
>
> The table has no index.  It has 5120000 records; field "foo" has only
> four distinct values.
>
> No matter whether I compiled with the system qsort or the qsort from
> FreeBSD, I got roughly equivalent results running psql under time.  I
> know that's hardly an ideal test, but as Tom suggested, the 32-bit
> case seemed to be so astonishingly bad that it should have been
> enough.  I ran the test repeatedly, and the results seem pretty
> consistent.  Here are some typical results:
>
> system lib:
>
> src$ time psql -p 12000 -o /dev/null -c "select * from table1 order
> ^by foo" test1
>
> real    29m23.822s
> user    2m10.241s
> sys     0m7.432s
>
> FreeBSD lib:
>
> postgresql-7.2.1$ time psql -p 12000 -o /dev/null -c "select * from
> table1 order by foo" test1
>
>
> real    29m38.880s
> user    2m10.571s
> sys     0m8.032s
>
>
> This example suggests the FreeBSD library is slightly worse in the
> 64-bit case.  That's consistently the case, but the difference is not
> so great that I'd put any stock in it.
>
> I do not know whether there might be any trouble using the FreeBSD
> library in a 64-bit configuration.  I'd say, if you're going to use a
> 64-bit postmaster, use the Solaris libraries.
>
> Hope this is helpful,
>
> A
>
> --
> ----
> Andrew Sullivan                               87 Mowat Avenue
> Liberty RMS                           Toronto, Ontario Canada
> <andrew@libertyrms.info>                              M6K 3E3
>                                          +1 416 646 3304 x110
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

pgsql-general by date:

Previous
From: Doug Fields
Date:
Subject: Re: is there any backend (server) timeout
Next
From: Mitch Vincent
Date:
Subject: Re: is there any backend (server) timeout