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

Re: [HACKERS] Not 7.5, but 8.0 ?

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: pgsql-hackers(at)postgresql(dot)org, pgsql-advocacy(at)postgresql(dot)org
Subject: Re: [HACKERS] Not 7.5, but 8.0 ?
Date: 2003-11-18 12:54:57
Message-ID: 3FBA16A1.2030500@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackers

Claudio Natoli wrote:

>>>I'm sorry if I'm being alow here - is there any problem  with running a 
>>>production server on cygwin's postgresql? Is the cygwin port of lesser 
>>>quality, or otherwise inferior?
>>>      
>>>
>>Performance, performance, perfomance... and perfomance... it is (almost) 
>>always worse perfomance when we emulate something... and using Cygwin we 
>>  are emulating U*nix...
>>    
>>
>
>Absolutely. The DB throughput available to our application with postgresql
>under cygwin is about 1/3 of what we get under Linux with a similar spec
>machine/config.
>
>That, and, more importantly, the odd spurious cygipc lock up, precludes our
>use of postgresql/cygwin in a production setting. And not having postgresql
>available on all our target platforms (which includes Windows) precludes the
>use of it at all, as we desire a single DB solution. I don't imagine we are
>the only ones in this situation (and to all those who see a Windows port as
>"uninteresting", please keep this in mind).
>

You are far from alone. And there's one other factor: most large 
enterprises have quite strict policies about what can be installed on 
their data center servers. Getting Cygwin past those policies would 
often be difficult. That factor alone was enough to make my product 
manager rule Postgres out as a solution that we would bundle with our 
software.

>
>Hopefully, we can change this situation soon...
>
>  
>

Right.

Here's the situation as I see it:
. there have been lots of requests for a native Win32 port
. this is important to some people and not important to others
. the decision has long ago been made to do it, and some work has been 
done, and more is being done

Isn't it time to move on?

As for release numbering, ISTM that is not fundamentally very important. 
At my former company we had code names for branches and decided release 
names/numbers near release time in accordance with marketing 
requirements. Let's not get hung up on nominalism. A release number is 
just a tag and we can call it whatever seems good at the time.

cheers

andrew


In response to

Responses

pgsql-hackers by date

Next:From: Marek LewczukDate: 2003-11-18 13:00:19
Subject: Re: [HACKERS] Not 7.5, but 8.0 ?
Previous:From: Michael GlaesemannDate: 2003-11-18 12:30:06
Subject: Re: [HACKERS] Release cycle length

pgsql-advocacy by date

Next:From: Marek LewczukDate: 2003-11-18 13:00:19
Subject: Re: [HACKERS] Not 7.5, but 8.0 ?
Previous:From: Claudio NatoliDate: 2003-11-18 12:26:19
Subject: Re: [HACKERS] Not 7.5, but 8.0 ?

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