Skip site navigation (1) Skip section navigation (2)

Re: Committing Resources to Win32

From: "Jim Jones" <jjones(at)aantix(dot)com>
To: <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: Committing Resources to Win32
Date: 2003-11-11 00:15:29
Message-ID: 001b01c3a7e8$e9f22e40$0300000a@chatserver (view raw or whole thread)
Lists: pgsql-hackers-win32
If you guys have already discussed the following possibilities, I
apologize.  I joined the list late.

The correct way to create a high performance server on the Windows
platform (NT, Advanced Server, etc) is to utilize IO Completion Ports.
The kernel will manage your connection pool and threading for you.  Any
object that is serializable can utilize this model (sockets, files,

If one thread becomes busy with processing, a second worker thread is
awoken, and it performs the processing. Sockets and threads are all
preallocated to increase performance.

Here are a couple informative articles on the subject :

Writing scalable server applications using IOCP

Developing a Truly Scalable Winsock Server using IO Completion Ports

The Microsoft SDK comes with a free compiler, but you will have access
to only the API functions, none of the frameworks (MFC, ATL, etc).


-----Original Message-----
From: pgsql-hackers-win32-owner(at)postgresql(dot)org
[mailto:pgsql-hackers-win32-owner(at)postgresql(dot)org] On Behalf Of Joshua D.
Sent: Monday, November 10, 2003 4:57 PM
To: Andrew Dunstan
Cc: pgsql-hackers-win32(at)postgresql(dot)org
Subject: Re: [pgsql-hackers-win32] Committing Resources to Win32

> *nod*
> Joshua, can you tell us any more about the nature of your client's 
> app(s)? Speculating like this in the dark is a bit fruitless.
I can't legally tell you much but what I can tell you is:

There application creates a great deal of processes that open and close.

On Linux which has a very light process model the performance hit is 
nominal. On platforms like Win32 or Solaris where processes are 
expensive, under heavy load you can see a pretty significant increase in

performance by going to a threaded model.

They are currently running our Cygwin installation which combined with 
connection pooling has provided "ok" performance but nothing
worth writing home about (especially considering they compared against 

I am not going to lie, from a Windows perspective I am a little bit of a

PHB. I don't develop (personally) on Windows. However the
customer requirements are simple:

Command Prompt needs to provide a native Win32 PostgreSQL version that 
supplies a reasonable proximity of performance
per the Linux native version. The Win32 native version must also 
maintain the same level of transactibility as the Linux version.

My customer is a house of Windows C/C++ and they are telling me that 
using CreateProcess will not generate that proximity.

They and I could be totally on crack, but my own research suggests 
pretty much the same thing and the Windows programmers
that I have talked to that are not associated with this customer also 
say the same thing.

What this all comes down to for us is this:

Can we (the community) develop a Win32 native version using 
CreateProcess that will scale and perform at a level that
is acceptable to wide general use. Understanding that for many 
operations PostgreSQL on Linux will perform as well if
not faster than the other well known database with the letter O in their



Joshua Drake

> cheers
> andrew
> ---------------------------(end of
> TIP 5: Have you checked our extensive FAQ?

Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - jd(at)commandprompt(dot)com -
Editor-N-Chief - PostgreSQl.Org -

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?


In response to


pgsql-hackers-win32 by date

Next:From: Bruce MomjianDate: 2003-11-11 01:34:27
Subject: Re: Other Win32 TODO items?
Previous:From: Andrew DunstanDate: 2003-11-11 00:04:19
Subject: Re: Committing Resources to Win32

Privacy Policy | About PostgreSQL
Copyright © 1996-2016 The PostgreSQL Global Development Group