Re: [HACKERS] Re : Solaris Performance - 64 bit puzzle

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Andrew Sullivan <andrew(at)libertyrms(dot)info>
Cc: pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Re : Solaris Performance - 64 bit puzzle
Date: 2002-05-28 01:00:43
Message-ID: 200205280100.g4S10hv23955@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers


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(at)libertyrms(dot)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(at)postgresql(dot)org)
>

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Mitch Vincent 2002-05-28 01:12:21 Re: is there any backend (server) timeout
Previous Message Doug Fields 2002-05-27 23:18:02 Re: is there any backend (server) timeout

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2002-05-28 01:07:46 Re: pgstatindex
Previous Message Manuel Sugawara 2002-05-27 22:28:22 Re: is there any backend timeout undocumented?