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

Re: scalability issues on win32

From: Reini Urban <rurban(at)x-ray(dot)at>
To: Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org,PostgreSQL Win32 port list <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: scalability issues on win32
Date: 2004-11-23 10:19:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers-win32pgsql-performance
Merlin Moncure schrieb:
> Following is the promised writeup in performance related issues
> comparing win32 with linux x86 and linux x86-64.  Unfortunately, the 64
> bit portion of the test is not yet completed and won't be for a bit.
> However there are some telling things about the win32/linux comparison.
> If you are considering deploying postgres in a win32 environment read
> on...
> First a description of the client app:
> Our company develops an ERP/CRM written in cobol which we are porting to
> run on PostgreSQL.  Part of this porting effort was development of an
> ISAM 'driver' for our app to allow it to store/fetch data from the
> database in place of a traditional file system, which is complete.
> For those of you unfamiliar with COBOL/ISAM, applications written with
> it have a 'one record at a time' mentality, such the application tends
> to spam the server with queries of the select * from t where k = k1
> variety.  Our driver creates stored procedures as necessary and uses
> ExecParams wherever possible to cut down on server CPU time, which is a
> precious resource in our case.  Over time we plan to gradually redeploy
> our application logic to make better use of the sql server's server side
> power.  Our application is very rarely i/o bound because we will make
> sure our server has enough memory so that the data will be rarely, if
> ever, *not* run from the cache.
> A good benchmark of our application performance is the time it takes to
> read the entire bill of materials for a product.  This is a recursive
> read of about 2500 records in the typical case (2408 in the test case).

I always knew that COBOL ultimativly looses, but it's always refreshing 
to get confirmation from time to time :)

> Test platform:
> Pentium 4 3.06 GHz/HT
> 10k SATA Raptor
> 1Gb memory
> Windows XP Pro SP2/Redhat Fedora 3 (64 bit results coming soon)
> BOM traversal for product ***** (1 user): 
> win32: runtime: 3.34 sec  avg cpu load: 60%
> redhat: runtime: 3.46 sec  avg cpu load: 20%

Where did you get the win32 "avg cpu load" number from? AFAIK there's no 
getloadavg() for windows. At least I tried hard to find one, because I 
want to add a comparable figure to cygwin core. emacs, coreutils, make 
and others would need desperately need it, not to speak of servers and 
real-time apps.
Did you read it from taskman, or did you come up with your self-written 
solution? In taskman there's afaik no comparable figure. But there 
should be some perfmon api, which would do the trick.


"The load average (LA) is the average number of processes (the sum of 
the run queue length and the number of jobs currently running) that are 
ready to run, but are waiting for access to a busy CPU."

And thanks for the overview!
Reini Urban

In response to

pgsql-performance by date

Next:From: Dave PageDate: 2004-11-23 10:35:54
Subject: Re: scalability issues on win32
Previous:From: Pierre-Frédéric CaillaudDate: 2004-11-23 08:39:52
Subject: Re: Data type to use for primary key

pgsql-hackers-win32 by date

Next:From: Dave PageDate: 2004-11-23 10:35:54
Subject: Re: scalability issues on win32
Previous:From: Tony and Bryn ReinaDate: 2004-11-23 09:20:54
Subject: Re: Beta5 libpq Build broken with MS .NET 2003

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