Tom Lane wrote: > Paul Tillotson <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend