From: | "Guy Rouillier" <guyr(at)masergy(dot)com> |
---|---|
To: | "PostgreSQL General" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Performance tuning on RedHat Enterprise Linux 3 |
Date: | 2004-12-07 18:20:22 |
Message-ID: | CC1CF380F4D70844B01D45982E671B2348E479@mtxexch01.add0.masergy.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
> Paul Tillotson <pntil(at)shentel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bob Powell | 2004-12-07 18:32:48 | Create AS question |
Previous Message | MaRCeLO PeReiRA | 2004-12-07 17:49:14 | Simple function |