Re: Spinlock performance improvement proposal - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Spinlock performance improvement proposal
Date
Msg-id 15403.1001564360@sss.pgh.pa.us
Whole thread Raw
In response to Re: Spinlock performance improvement proposal  ("D. Hageman" <dhageman@dracken.com>)
Responses Re: Spinlock performance improvement proposal  (Myron Scott <mscott@sacadia.com>)
List pgsql-hackers
"D. Hageman" <dhageman@dracken.com> writes:
> If you look at Myron Scott's post today you will see that it had other 
> advantages going for it (like auto-vacuum!) and disadvantages ... rogue 
> thread corruption (already debated today).

But note that Myron did a number of things that are (IMHO) orthogonal
to process-to-thread conversion, such as adding prepared statements,
a separate thread/process/whateveryoucallit for buffer writing, ditto
for vacuuming, etc.  I think his results cannot be taken as indicative
of the benefits of threads per se --- these other things could be
implemented in a pure process model too, and we have no data with which
to estimate which change bought how much.

Threading certainly should reduce the context switch time, but this
comes at the price of increased overhead within each context (since
access to thread-local variables is not free).  It's by no means
obvious that there's a net win there.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alex Pilosov
Date:
Subject: Re: Spinlock performance improvement proposal
Next
From: Tatsuo Ishii
Date:
Subject: multibyte performance