On Tue, 6 Feb 2001, Karel Zak wrote:
>
> On Tue, 6 Feb 2001, Myron Scott wrote:
>
> > There are many many globals I had to work around including all the memory
> > management stuff. I basically threw everything into and "environment"
> > variable which I stored in a thread specific using thr_set
On Tue, 6 Feb 2001, Myron Scott wrote:
> There are many many globals I had to work around including all the memory
> management stuff. I basically threw everything into and "environment"
> variable which I stored in a thread specific using thr_setspecific.
Yes, it's good. I working on multi-t
>
> Sorry I haven't time to see and test your experiment,
> but I have a question. How you solve memory management?
> The current mmgr is based on global variable
> CurrentMemoryContext that is very often changed and used.
> Use you for this locks? If yes it is probably problematic
> point fo
On Mon, 5 Feb 2001, Myron Scott wrote:
> I have put a new version of my multi-threaded
> postgresql experiment at
>
> http://www.sacadia.com/mtpg.html
>
> This one actually works. I have added a server
> based on omniORB, a CORBA 2.3 ORB from ATT. It
>is much smaller than TAO and uses the
I have put a new version of my multi-threaded
postgresql experiment at
http://www.sacadia.com/mtpg.html
This one actually works. I have added a server
based on omniORB, a CORBA 2.3 ORB from ATT. It
is much smaller than TAO and uses the thread per
connection model. I haven't added the java
* Myron Scott <[EMAIL PROTECTED]> [010102 08:47] wrote:
>
>
> Alfred Perlstein wrote:
>
>
> >
> > It's possible what you're seeing is the entire process
> > wait for a disk IO to complete.
> >
> > I'm wondering, how many lwps does your system use? Are all
> > the threads bound to a single l
Alfred Perlstein wrote:
>
> It's possible what you're seeing is the entire process
> wait for a disk IO to complete.
>
> I'm wondering, how many lwps does your system use? Are all
> the threads bound to a single lwp or do you let the threads
> manager handle this all for you?
>
Yeah, I lo
* Myron Scott <[EMAIL PROTECTED]> [010102 07:45] wrote:
>
> Karel Zak wrote:
>
> > On Tue, 2 Jan 2001, Myron Scott wrote:
> >
> >
> >> spinlocks rewritten to mutex_
> >> locktable uses sema_
> >> some cond_ in bufmgr.c
> >
> >
> > Interesting, have you some comperation between IPC Postg
Karel Zak wrote:
> On Tue, 2 Jan 2001, Myron Scott wrote:
>
>
>> spinlocks rewritten to mutex_
>> locktable uses sema_
>> some cond_ in bufmgr.c
>
>
> Interesting, have you some comperation between IPC PostgresSQl anf
> your thread based PostgreSQL.
>
> Karel
Yes, I did some compari
spinlocks rewritten to mutex_
locktable uses sema_
some cond_ in bufmgr.c
Myron
Karel Zak wrote:
> On Mon, 1 Jan 2001, Myron Scott wrote:
>
>
>> For anyone interested,
>>
>> I have posted my multi-threaded version of PostgreSQL here.
>>
>> http://www.sacadia.com/mtpg.html
>
>
> How you
On Mon, 1 Jan 2001, Myron Scott wrote:
> For anyone interested,
>
> I have posted my multi-threaded version of PostgreSQL here.
>
> http://www.sacadia.com/mtpg.html
How you solve locks? Via original IPC or you rewrite it to mutex (etc).
Karel
For anyone interested,
I have posted my multi-threaded version of PostgreSQL here.
http://www.sacadia.com/mtpg.html
It is based on 7.0.2 and the TAO CORBA ORB which is here.
http://www.cs.wustl.edu/~schmidt/TAO.html
Myron Scott
[EMAIL PROTECTED]
> > The cons side of processes model is not the startup time. It is about
> > kernel resource and context-switch cost. Processes consume much more
> > kernel resource than threads, and have a much higher cost for context
> > switch. The scalability of threads model is much better than that of
> >
> This brings up a good point. Threads are mostly useful when you have
> multiple processes that need to share lots of data, and the interprocess
> overhead is excessive. Because we already have that shared memory area,
> this benefit of threads doesn't buy us much. We sort of already have
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> There is no difference. If anything bad happens with the current
> >> multi-process server, all the postgres backends shutdown because the
> >> shared memory may be corrupted.
>
> > Yes. Are we adding reliability with per-process backends.
>
> Y
-- Start of PGP signed section.
> On Mon, Nov 27, 2000 at 11:42:24PM -0600, Junfeng Zhang wrote:
> > I am new to postgreSQL. When I read the documents, I find out the Postmaster
> > daemon actual spawns a new backend server process to serve a new client
> > request. Why not use threads instead? Is
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> There is no difference. If anything bad happens with the current
>> multi-process server, all the postgres backends shutdown because the
>> shared memory may be corrupted.
> Yes. Are we adding reliability with per-process backends.
Yes, we are: the
> All the major operating systems should have POSIX threads implemented.
> Actually this can be configurable--multithreads or one thread.
>
> Thread-only server is unsafe, I agree. Maybe the following model can be a
> little better. Several servers, each is multi-threaded. Every server can
> supp
> Bruce Guenter <[EMAIL PROTECTED]> writes:
> > [ some very interesting datapoints ]
> >
> > So, forking a process with lots of data is expensive. However, most of
> > the PostgreSQL data is in a SysV IPC shared memory segment, which
> > shouldn't affect the fork numbers.
>
> I believe (but don'
> Adam Haberlach writes:
> > Typically (on a well-written OS, at least), the spawning of a thread
> > is much cheaper then the creation of a new process (via fork()).
>
> This would be well worth testing on some representative sample
> systems.
>
> Within the past year and a half at one of my gi
>
> On Mon, 4 Dec 2000, Junfeng Zhang wrote:
>
> > All the major operating systems should have POSIX threads implemented.
> > Actually this can be configurable--multithreads or one thread.
>
> I don't understand this. The OS can be configured for one thread? How
> would that be any of use?
On Tue, Dec 05, 2000 at 02:52:48PM -0500, Tom Lane wrote:
> There aren't going to be all that many data pages needing the COW
> treatment, because the postmaster uses very little data space of its
> own. I think this would become an issue if we tried to have the
> postmaster pre-cache catalog inf
[EMAIL PROTECTED] writes:
> The process vs threads benchmark which showed 160us vs 120us, only did
> the process creation, not the delayed hit of the "copy on write" pages
> in the new process. Just forking is not as simple as forking, once the
> forked process starts to work, memory that is not e
I have been watching this thread vs non-threaded discussion and am completely with the
process-only crew for a couple reasons, but lets look at a few things:
The process vs threads benchmark which showed 160us vs 120us, only did the process
creation, not the delayed hit of the "copy on write" pag
On Mon, Dec 04, 2000 at 08:43:24PM -0800, Tom Samplonius wrote:
> Some OSes (Linux is the main one) implement threads as pseudo processes.
> Linux threads are processes with a shared address space and file
> descriptor table.
>
> Context switch cost for threads can be lower if you are switchi
On Tue, Dec 05, 2000 at 10:07:37AM +0100, Zeugswetter Andreas SB wrote:
> > And using the following program for timing thread creation
> > and cleanup:
> >
> > #include
> >
> > threadfn() { pthread_exit(0); }
>
> I think you would mainly need to test how the system behaves, if
> the threads
> And using the following program for timing thread creation
> and cleanup:
>
> #include
>
> threadfn() { pthread_exit(0); }
I think you would mainly need to test how the system behaves, if
the threads and processes actually do some work in parallel, like:
threadfn() {int i; for (i=0; i<10
On Mon, 4 Dec 2000, Junfeng Zhang wrote:
> All the major operating systems should have POSIX threads implemented.
> Actually this can be configurable--multithreads or one thread.
I don't understand this. The OS can be configured for one thread? How
would that be any of use?
> Thread-only s
Bruce Guenter <[EMAIL PROTECTED]> writes:
> [ some very interesting datapoints ]
>
> So, forking a process with lots of data is expensive. However, most of
> the PostgreSQL data is in a SysV IPC shared memory segment, which
> shouldn't affect the fork numbers.
I believe (but don't have numbers t
I would love to distribute this code to anybody who wants it. Any
suggestions for a good place? However, calling the
work a code redesign is a bit generous. This was more like a
brute force hack. I just moved all the connection related global
variables to
a thread local "environment variable"
Matthew wrote:
> The primary advantage that I see is that a single postgres process
> can benefit from multiple processors. I see little advantage to using thread
> for client connections.
Multiprocessors best benefit multiple backends. And the current forked
model lends itself admirably
On Mon, Dec 04, 2000 at 02:30:31PM -0800, Dan Lyke wrote:
> Adam Haberlach writes:
> > Typically (on a well-written OS, at least), the spawning of a thread
> > is much cheaper then the creation of a new process (via fork()).
> This would be well worth testing on some representative sample
> system
*snip*
> >
> > Once all the questions regarding "why not" have been answered, it would
> > be good to also ask "why use threads?" Do they simplify the code? Do
> > they offer significant performance or efficiency gains? What do they
> > give, other than being buzzword compliant?
>
On Mon, Dec 04, 2000 at 03:17:00PM -0800, Adam Haberlach wrote:
> Typically (on a well-written OS, at least), the spawning of a thread
> is much cheaper then the creation of a new process (via fork()).
Unless I'm mistaken, the back-end is only forked when starting a new
connection, in which
Adam Haberlach writes:
> Typically (on a well-written OS, at least), the spawning of a thread
> is much cheaper then the creation of a new process (via fork()).
This would be well worth testing on some representative sample
systems.
Within the past year and a half at one of my gigs some coworker
On Mon, Dec 04, 2000 at 02:28:10PM -0600, Bruce Guenter wrote:
> On Mon, Nov 27, 2000 at 11:42:24PM -0600, Junfeng Zhang wrote:
> > I am new to postgreSQL. When I read the documents, I find out the Postmaster
> > daemon actual spawns a new backend server process to serve a new client
> > request.
All the major operating systems should have POSIX threads implemented.
Actually this can be configurable--multithreads or one thread.
Thread-only server is unsafe, I agree. Maybe the following model can be a
little better. Several servers, each is multi-threaded. Every server can
support a maximu
On Mon, Nov 27, 2000 at 11:42:24PM -0600, Junfeng Zhang wrote:
> I am new to postgreSQL. When I read the documents, I find out the Postmaster
> daemon actual spawns a new backend server process to serve a new client
> request. Why not use threads instead? Is that just for a historical reason,
> or
The Hermit Hacker <[EMAIL PROTECTED]> writes:
>> Why not use threads instead? Is that just for a
>> historical reason, or some performance/implementation concern?
> Several reasons, 'historical' probably being the strongest right now
> ... since PostgreSQL was never designed for threading, its ab
if we were to do this in steps, I beliee that one of the major problems
irght now is that we have global variables up the wazoo ... my
'thread-awareness' is limited, as I've yet to use them, so excuse my
ignorance ... if we got patches that cleaned up the code in stages, moving
towards a cleaner
Myron -
Putting aside the fork/threads discussion for a moment (the reasons,
both historical and other, such as inter-backend protection, are well
covered in the archives), the work you did sounds like an interesting
experiment in code redesign. Would you be willing to release the hacked
code som
On Mon, 27 Nov 2000, Junfeng Zhang wrote:
> Hello all,
>
> I am new to postgreSQL. When I read the documents, I find out the
> Postmaster daemon actual spawns a new backend server process to serve
> a new client request. Why not use threads instead? Is that just for a
> historical reason, or som
I maybe wrong but I think that PGSQL is not threaded mostly due to
historical reasons. It looks to me like the source has developed over
time where much of the source is not reentrant with many global variables
throughout. In addition, the parser is generated by flex which
can be made to generat
On Mon, 27 Nov 2000, Junfeng Zhang wrote:
> Hello all,
>
> I am new to postgreSQL. When I read the documents, I find out the Postmaster
> daemon actual spawns a new backend server process to serve a new client
> request. Why not use threads instead? Is that just for a historical reason,
> or som
Hello all,
I am new to postgreSQL. When I read the documents, I find out the Postmaster
daemon actual spawns a new backend server process to serve a new client
request. Why not use threads instead? Is that just for a historical reason,
or some performance/implementation concern?
Thank you very m
45 matches
Mail list logo
