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
Re: [HACKERS] Re : Solaris Performance - 64 bit puzzle |
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: