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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-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

Browse pgsql-advocacy by date

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

Browse pgsql-hackers by date

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