On Wed, 6 Feb 2002 mkscott@sacadia.com wrote:
> After revisiting the threaded code after a long break I now see some
> real benefits to threading. For example, I was able to incorporate Tom
> Lane's lazy_vacuum code to do relation clean up automatically when a
> threshold of page writes occurred. I was also able to use the freespace
> information to be shared among threads in the process without touching
> shared mem. As a result, a pgbench run with 20 clients and over
> 1,000,000 trasactions maintained a more or less constant tps with manual
> vacuum commands and far less heap expansion. You can do this with
> processes (planned for 7.3 I think) but I think it was much easier with
> threads. Other things may open up with threads as well like Java stored
> procedures. Anyway, now I think it is worth it.
Are there code clean-ups that have gone into the thread'd code that could
be incorporated into the existing code base that would start us down that
path? For instance, based my limited understanding of threaded servers, I
believe that 'global variables' are generally considered "A Real Bad
Thing" ... in one of your email's, you mentioned:
"The first basic problem is that global variables are scattered throughout
the source as well as some static stack variables. Hunting these down and
finding a home for them is, in and of itself, a major task. For example,
flex produces code that is not thread safe, you have to modify that too.
The current work around in exper. thrreaded postgres is not pretty, one
"environment" structure that holds all the normal postgres globals in
thread local storage. This makes compile time choices impractical I
think."
Now, what is a 'clean' solution to this? Making sure that all variables
are passed through to various functions, maybe through a struct construct?
So, can we start there and work our way through the code? Start simple
... take one of the global(s), put it into the struct and take it out of
global space and make sure that its passed appropriately through all the
required functions ... add in the next one, and do another trace?
Someone, or a group of ppl, with thread knowledge needs to start this
forward ... once the clean up begins, even without any thread code thrown
in, it shouldn't be too difficult to keep it clean to go to 'the next
step', no?
