Re: Performance tuning on RedHat Enterprise Linux 3 - Mailing list pgsql-general

From Guy Rouillier
Subject Re: Performance tuning on RedHat Enterprise Linux 3
Date
Msg-id CC1CF380F4D70844B01D45982E671B2348E479@mtxexch01.add0.masergy.com
Whole thread Raw
In response to Performance tuning on RedHat Enterprise Linux 3  ("David Esposito" <pgsql-general@esposito.newnetco.com>)
Responses Re: Performance tuning on RedHat Enterprise Linux 3  (Paul Tillotson <pntil@shentel.net>)
List pgsql-general
Tom Lane wrote:
> Paul Tillotson <pntil@shentel.net> writes:
>> Does postgres actually do multiple concurrent sorts within a single
>> backend?
>
> Certainly.  Consider for example a merge join with each input being
> sorted by an explicit sort step.  DISTINCT, ORDER BY, UNION, and
> related operators require their own sort steps in the current
> implementation. It's not difficult to invent queries that require
> arbitrarily large numbers of sort steps.

Tom, in Bruce's document on performance tuning, the page titled
"Multiple CPUs" states:

"POSTGRESQL uses a multi-process model, meaning each database connection
has its own Unix process...POSTGRESQL does not use multi-threading to
allow a single process to use multiple CPUs."

I took this to mean that PostgreSQL was not multi-threaded at all, and
that each connection was serviced by a single, non-threaded process.
Have I interpreted this incorrectly?  Are you saying that the backend
process actually is multi-threaded?  In the example you site, multiple
sorts could be accomplished serially in a non-threaded process.

--
Guy Rouillier


pgsql-general by date:

Previous
From: Stan Y
Date:
Subject: Measure the CPU Time per Transaction
Next
From: Greg Stark
Date:
Subject: Re: Performance tuning on RedHat Enterprise Linux 3