mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-21 03:53:30 +02:00
69 lines
3.6 KiB
Plaintext
69 lines
3.6 KiB
Plaintext
From pgsql-hackers-owner+M13599=candle.pha.pa.us=pgman@postgresql.org Wed Sep 26 17:25:32 2001
|
|
Return-path: <pgsql-hackers-owner+M13599=candle.pha.pa.us=pgman@postgresql.org>
|
|
Received: from server1.pgsql.org (server1.pgsql.org [64.39.15.238] (may be forged))
|
|
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id f8QLPWo07589
|
|
for <pgman@candle.pha.pa.us>; Wed, 26 Sep 2001 17:25:32 -0400 (EDT)
|
|
Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
|
|
by server1.pgsql.org (8.11.6/8.11.6) with ESMTP id f8QLPf405606
|
|
for <pgman@candle.pha.pa.us>; Wed, 26 Sep 2001 16:25:41 -0500 (CDT)
|
|
(envelope-from pgsql-hackers-owner+M13599=candle.pha.pa.us=pgman@postgresql.org)
|
|
Received: from gromit.dotclick.com (ipn9-f8366.net-resource.net [216.204.83.66])
|
|
by postgresql.org (8.11.3/8.11.4) with ESMTP id f8QKj3h82020
|
|
for <pgsql-hackers@postgresql.org>; Wed, 26 Sep 2001 16:45:03 -0400 (EDT)
|
|
(envelope-from markw@mohawksoft.com)
|
|
Received: from mohawksoft.com (IDENT:markw@localhost.localdomain [127.0.0.1])
|
|
by gromit.dotclick.com (8.9.3/8.9.3) with ESMTP id QAA23693;
|
|
Wed, 26 Sep 2001 16:43:02 -0400
|
|
Message-ID: <3BB23DD6.E86AF327@mohawksoft.com>
|
|
Date: Wed, 26 Sep 2001 16:43:02 -0400
|
|
From: mlw <markw@mohawksoft.com>
|
|
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.2 i686)
|
|
X-Accept-Language: en
|
|
MIME-Version: 1.0
|
|
To: "D. Hageman" <dhageman@dracken.com>,
|
|
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
|
|
Subject: Re: [HACKERS] Spinlock performance improvement proposal
|
|
References: <Pine.LNX.4.33.0109261330030.1906-100000@typhon.dracken.com>
|
|
Content-Type: text/plain; charset=us-ascii
|
|
Content-Transfer-Encoding: 7bit
|
|
Precedence: bulk
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
Status: OR
|
|
|
|
"D. Hageman" wrote:
|
|
|
|
> The plan for the new spinlocks does look like it has some potential. My
|
|
> only comment in regards to permformance when we start looking at SMP
|
|
> machines is ... it is my belief that getting a true threaded backend may
|
|
> be the only way to get the full potential out of SMP machines. I see that
|
|
> is one of the things to experiment with on the TODO list and I have seen
|
|
> some people have messed around already with this using Solaris threads.
|
|
> It should probably be attempted with pthreads if PostgreSQL is going to
|
|
> keep some resemblance of cross-platform compatibility. At that time, it
|
|
> would probably be easier to go in and clean up some stuff for the
|
|
> implementation of other TODO items (put in the base framework for more
|
|
> complex future items) as threading the backend would take a little bit of
|
|
> ideology shift.
|
|
|
|
I can only think of two objectives for threading. (1) running the various
|
|
connections in their own thread instead of their own process. (2) running
|
|
complex queries across multiple threads.
|
|
|
|
For item (1) I see no value to this. It is a lot of work with no tangible
|
|
benefit. If you have an old fashion pthreads implementation, it will hurt
|
|
performance because are scheduled within the single process's time slice.. If
|
|
you have a newer kernel scheduled implementation, then you will have the same
|
|
scheduling as separate processes. The only thing you will need to do is
|
|
switch your brain from figuring out how to share data, to trying to figure
|
|
out how to isolate data. A multithreaded implementation lacks many of the
|
|
benefits and robustness of a multiprocess implementation.
|
|
|
|
For item (2) I can see how that could speed up queries in a low utilization
|
|
system, and that would be cool, but in a server that is under load, threading
|
|
the queries probably be less efficient.
|
|
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
|
|