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

Re: Committing Resources to Win32

From: Marsh Ray <marsh-pg(at)mysteray(dot)com>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Marsh Ray <marsh-pg(at)mysteray(dot)com>, jjones(at)aantix(dot)com,pgsql-hackers-win32(at)postgresql(dot)org
Subject: Re: Committing Resources to Win32
Date: 2003-11-12 03:20:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers-win32
Joshua D. Drake wrote:

> Marsh wrote:
>> I would think that you could probably get 80% of the performance with 
>> ordinary threads and ordinary blocking IO, and without the great 
>> increase in complexity required to implement asynchronous IO. If 
>> someone then wants to go after a possible 25% performance gain, they 
>> could submit a working set of modifications, or wait a few months for 
>> the hardware to catch up.
> This argument doesn't work for several reasons:
> 1. Hardware generally does not catch up because:
>       A. Users demand increases and thus the load on the hardware 
> increases.
>       B. Users don't purchase new hardware every couple of months.
> 2. If we were talking about a 5% performance gain that "might" be 
> acceptable but
> the 20% gain you are talking about is huge. Think about it:
>    I have several customers right now that push over 250,000 (some as 
> high as 750,000)
> transactions an hour. They are pushing the hardware hard as it is, 
> especially with the
> limitations of Vacuum. If they were to move to the Win32 version (it 
> doesn't matter why),
> they would loose 50,000 transactions an hour based on your argument.
>    That is completely illegitamate and would make PostgreSQL look like 
> a toy on Windows.
> We already have PostgreSQL as a toy on Windows, it uses Cygwin.

OK, but are you using asych IO on any platform now?

Note that the original poster proposed it as a possible performance 
enhancement, and I'm not claiming that a threaded blocking-IO 
implementation on Windows is going to be slower than the current model 
on Unix.

The hypothetical 25% gain really is a WAG that would probably only be 
achievable for some current worst-case scenarios, but the point is it 
represents a few months of hardware advance. If somebody's servers are 
really that saturated, they will be looking at hardware upgrades sooner 
rather than later, and a similar effect might achieved by throwing RAM 
at the problem.

Ideally you would have a single process with exactly as many threads as 
there are CPUs (maybe x2 for Intel HyperThreading chips). Each thread 
would have affinity to a specific processor. All IO would be done 
asynchronously and use coroutines/fibers for task switching.

Due to the complexity involved in implementing an app this way, it's 
usually not done. Process- or thread-per-connection with blocking IO is 
conceptionally much simpler and usually not that much slower. Efficient 
CPU scheduling is one of the main functions of the mainstream OS, right?

- Marsh

In response to


pgsql-hackers-win32 by date

Next:From: Bruce MomjianDate: 2003-11-12 03:33:19
Subject: Re: Committing Resources to Win32
Previous:From: Merlin MoncureDate: 2003-11-11 20:10:22
Subject: Re: Committing Resources to Win32

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