Re: Re :Solaris Performance - Mailing list pgsql-general

From Bruce Momjian
Subject Re: Re :Solaris Performance
Date
Msg-id 200202051737.g15HbKw15318@candle.pha.pa.us
Whole thread Raw
In response to Re: Re :Solaris Performance  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Tom Lane wrote:
> Mark kirkwood <markir@slingshot.co.nz> writes:
> > The problem area I have experienced is that queries that require a
> > reasonable sort at some point of the plan (e.g have a GROUP BY) will
> > consume all one 1 cpu (box had 2 of them) for a _very_ long time (e.g.
> > 30 minutes - using either compiler) whereas the same query on a (single
> > cpu) Intel/Linux takes about 1 minute.
>
> [ scratches head ... ]  I didn't think there was anything particularly
> system-dependent about the sorting code.  Have you tried profiling, or
> anything to determine where the Solaris version is spending its time?

The only thing I can think of that would affect the sorting code is
paging to swap during the sort.  But the default sort batch size is
512k, so it is hard to imagine it is paging out at that size.  You would
think it would affect normal backend operation, but maybe not.  Does
Solaris have a working-set concept where it will force to swap even if
no one else is using memory?  When I used VMS, we had that problem where
a process would only use a small amount of memory and force to swap even
though no one else was using the machine.  I just looked through my
Mauro Solaris internals book and I don't see any mention of working set
memory usage.

--
  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: Vivek Khera
Date:
Subject: Re: Indices for foreign keys
Next
From: Devrim GUNDUZ
Date:
Subject: about pg_dumpall