Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-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

pgsql-hackers by date

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

pgsql-general by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group