Native Win32 sources

They are in process for 7.4. There are a few non-source Win32
commercial distributions.

---------------------------------------------------------------------------

Ulrich Neumann wrote:

Hello,

i've read that there are 2 different native ports for Windows
somewhere.

I've searched for them but didn't found them. Is there anyone who can
point me to a link or send me a copy of the sources?

Thanks

Ulrich
----------------------------------
This e-mail is virus scanned
Diese e-mail ist virusgeprueft

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Ulrich Neumann wrote:

Hello,

i've read that there are 2 different native ports for Windows
somewhere.

I've searched for them but didn't found them. Is there anyone who can
point me to a link or send me a copy of the sources?

Oh, you are probably asking about the sources. They are not publically
available yet.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Is there a rough date for when they'll be available?

I have a development team at work who currently have an M$-Windows box and a
Linux box each in order to allow them to read M$-Office documents sent to us
and develop against PostgreSQL (which we use in production).

I know I could have a shared Linux box with multiple databases and have them
bind to that, but one of the important aspects of our application is
response time, and you can't accurately measure response times for code
changes on a shared system.

Having a Win32 native version would save a lot of hassles for me.

Al.

----- Original Message -----
From: "Bruce Momjian" <pgman@candle.pha.pa.us>
To: "Ulrich Neumann" <U_Neumann@gne.de>
Cc: <pgsql-hackers@postgresql.org>
Sent: Monday, November 25, 2002 5:51 PM
Subject: [mail] Re: [HACKERS] Native Win32 sources

Ulrich Neumann wrote:

Hello,

i've read that there are 2 different native ports for Windows
somewhere.

I've searched for them but didn't found them. Is there anyone who can
point me to a link or send me a copy of the sources?

Oh, you are probably asking about the sources. They are not publically
available yet.

--
Bruce Momjian                        |  http://candle.pha.pa.us
pgman@candle.pha.pa.us               |  (610) 359-1001
+  If your life is a hard drive,     |  13 Roberts Road
+  Christ can be your backup.        |  Newtown Square, Pennsylvania

19073

Al, to be honest I don't think the Windows native would save hassle,
rather it'd probably cause more! No disrespect to those doing the
version, read on for reasoning...

Yes, you get a beta of a Windows native version just now, yes it
probably will not be that long till the source is a available... But
how long till it's part of a cosha PostgreSQL release? Version
7.4... Could be up to six months... Do you want to run pre-release
versions in the meantime? Don't think so, not in a production
environment!

So, the real way to save hassle is probably a cheap commodity PC with
Linux installed... Or settle for the existing, non-native, Windows
version.

By the way, just to open Office documents? Have you tried OpenOffice?

Regards, Lee Kindness.

Al Sutton writes:

Lee,

I wouldn't go for 7.4 in production until after it's gone gold, but being
able to cut the number of boxes per developer by giving them a Win32 native
version would save on everything from the overhead of getting the developers
familiar enough with Linux to be able to admin their own systems, to cutting
the network usage by having the DB and app on the same system, through to
cutting the cost of electricity by only having one box per developer. It
would also be a good way of testing 7.4 against our app so we can plan for
an upgrade when it's released ;).

I've tried open office 1.0.1 and had to ditch it. It had problems with font
rendering and tables that ment many of the forms that people sent as word
documents had chunks that weren't displayed or printed. We did try it on a
box with MS-Word on it to ensure that the setup of the machine wasn't the
issue, Word had no problems, OO failed horribly.

Thanks for the ideas,

Al.

----- Original Message -----
From: "Lee Kindness" <lkindness@csl.co.uk>
To: "Al Sutton" <al@alsutton.com>
Cc: "Bruce Momjian" <pgman@candle.pha.pa.us>; "Ulrich Neumann"
<U_Neumann@gne.de>; <pgsql-hackers@postgresql.org>; "Lee Kindness"
<lkindness@csl.co.uk>
Sent: Tuesday, November 26, 2002 9:08 AM
Subject: Re: [mail] Re: [HACKERS] Native Win32 sources

Al, to be honest I don't think the Windows native would save hassle,
rather it'd probably cause more! No disrespect to those doing the
version, read on for reasoning...

Yes, you get a beta of a Windows native version just now, yes it
probably will not be that long till the source is a available... But
how long till it's part of a cosha PostgreSQL release? Version
7.4... Could be up to six months... Do you want to run pre-release
versions in the meantime? Don't think so, not in a production
environment!

So, the real way to save hassle is probably a cheap commodity PC with
Linux installed... Or settle for the existing, non-native, Windows
version.

By the way, just to open Office documents? Have you tried OpenOffice?

Regards, Lee Kindness.

Al Sutton writes:

Is there a rough date for when they'll be available?

I have a development team at work who currently have an M$-Windows box

and a

Linux box each in order to allow them to read M$-Office documents sent

to us

and develop against PostgreSQL (which we use in production).

I know I could have a shared Linux box with multiple databases and have

them

bind to that, but one of the important aspects of our application is
response time, and you can't accurately measure response times for code
changes on a shared system.

Having a Win32 native version would save a lot of hassles for me.

Al.

----- Original Message -----
From: "Bruce Momjian" <pgman@candle.pha.pa.us>

Ulrich Neumann wrote:

Hello,

i've read that there are 2 different native ports for Windows
somewhere.

I've searched for them but didn't found them. Is there anyone who

can

point me to a link or send me a copy of the sources?

Oh, you are probably asking about the sources. They are not

publically

On November 26, 2002 06:33 am, Al Sutton wrote:

I wouldn't go for 7.4 in production until after it's gone gold, but being
able to cut the number of boxes per developer by giving them a Win32 native
version would save on everything from the overhead of getting the
developers familiar enough with Linux to be able to admin their own
systems, to cutting the network usage by having the DB and app on the same
system, through to cutting the cost of electricity by only having one box
per developer. It would also be a good way of testing 7.4 against our app
so we can plan for an upgrade when it's released ;).

If your database is of any significant size you probably want a separate
database machine anyway. We run NetBSD everywhere and could easily put the
apps on the database machine but choose not to. We have 6 production servers
running various apps and web servers and they all talk to a central database
machine which has lots of RAM. Forget about bandwidth. Just get a 100MBit
switch and plug everything into it. Network bandwidth won't normally be your
bottleneck. Memory and CPU will be.

We actually have 4 database machines, 3 running transaction databases and 1
with an rsynced copy for reporting purposes. We use 3 networks, 1 for the
app servers to talk to the Internet, 1 for the app servers to talk to the
databases and one for the databases to talk amongst themselves.

Even for development we keep a separate database machine that developers all
use. They run whatever they want - we have people using NetBSD, Linux and
Windows - but they work on one database which is tuned for the purpose. They
can even create their own databases on that system if they want for local
testing.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

D'Arcy,

In production the database servers are seperate multi-processor machines
with mirrored disks linked via Gigabit ethernet to the app server.

In development I have people extremely familiar with MS, but not very hot
with Unix in any flavour, who are developing Java and PHP code which is then
passed into the QA phase where it's run on a replica of the production
environment.

My goal is to allow my developers to work on the platform they know (MS),
using as many of the aspects of the production environment as possible (JVM
version, PHP version, and hopefully database version), without needing to
buy each new developer two machines, and incur the overhead of them
familiarising themselves with a flavour of Unix.

Hope this helps you understand where I'm comming from,

Al.

----- Original Message -----
From: "D'Arcy J.M. Cain" <darcy@druid.net>
To: "Al Sutton" <al@alsutton.com>; "Lee Kindness" <lkindness@csl.co.uk>
Cc: <pgsql-hackers@PostgreSQL.org>
Sent: Tuesday, November 26, 2002 11:59 AM
Subject: Re: [mail] Re: [HACKERS] Native Win32 sources

On November 26, 2002 06:33 am, Al Sutton wrote:

I wouldn't go for 7.4 in production until after it's gone gold, but

being

able to cut the number of boxes per developer by giving them a Win32

native

version would save on everything from the overhead of getting the
developers familiar enough with Linux to be able to admin their own
systems, to cutting the network usage by having the DB and app on the

same

system, through to cutting the cost of electricity by only having one

box

per developer. It would also be a good way of testing 7.4 against our

app

so we can plan for an upgrade when it's released ;).

If your database is of any significant size you probably want a separate
database machine anyway. We run NetBSD everywhere and could easily put

the

apps on the database machine but choose not to. We have 6 production

servers

running various apps and web servers and they all talk to a central

database

machine which has lots of RAM. Forget about bandwidth. Just get a

100MBit

switch and plug everything into it. Network bandwidth won't normally be

your

bottleneck. Memory and CPU will be.

We actually have 4 database machines, 3 running transaction databases and

1

with an rsynced copy for reporting purposes. We use 3 networks, 1 for the
app servers to talk to the Internet, 1 for the app servers to talk to the
databases and one for the databases to talk amongst themselves.

Even for development we keep a separate database machine that developers

all

use. They run whatever they want - we have people using NetBSD, Linux and
Windows - but they work on one database which is tuned for the purpose.

They

On Tue, 26 Nov 2002, Al Sutton wrote:

D'Arcy,

In production the database servers are seperate multi-processor machines
with mirrored disks linked via Gigabit ethernet to the app server.

In development I have people extremely familiar with MS, but not very hot
with Unix in any flavour, who are developing Java and PHP code which is then
passed into the QA phase where it's run on a replica of the production
environment.

My goal is to allow my developers to work on the platform they know (MS),
using as many of the aspects of the production environment as possible (JVM
version, PHP version, and hopefully database version), without needing to
buy each new developer two machines, and incur the overhead of them
familiarising themselves with a flavour of Unix.

Hope this helps you understand where I'm comming from,

I know it's not windows native but using Cygwin would at least get you
out of the "two boxes on everybody's desktop" business. And for deveopers
the difference in performance isn't all that great, as the only real
performance issue is the one of creating / dropping backend connections is
kinda slow. Since they'd be running on their own boxes for testing, you
could probably just use persistant connections and get pretty good
performance. What web server are they using? If it's apache, just set
the number of max children down to something like 20 or so and they should
be fine.

Al Sutton wrote:

Lee,

I wouldn't go for 7.4 in production until after it's gone gold, but being
able to cut the number of boxes per developer by giving them a Win32 native
version would save on everything from the overhead of getting the developers
familiar enough with Linux to be able to admin their own systems, to cutting
the network usage by having the DB and app on the same system, through to
cutting the cost of electricity by only having one box per developer. It
would also be a good way of testing 7.4 against our app so we can plan for
an upgrade when it's released ;).

I've tried open office 1.0.1 and had to ditch it. It had problems with font
rendering and tables that ment many of the forms that people sent as word
documents had chunks that weren't displayed or printed. We did try it on a
box with MS-Word on it to ensure that the setup of the machine wasn't the
issue, Word had no problems, OO failed horribly.

www.peerdirect.com has a native PostgreSQL 7.2 release that should work
fine for you until 7.4. It is in beta, I think.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Al Sutton kirjutas T, 26.11.2002 kell 20:37:

D'Arcy,

In production the database servers are seperate multi-processor machines
with mirrored disks linked via Gigabit ethernet to the app server.

In development I have people extremely familiar with MS, but not very hot
with Unix in any flavour, who are developing Java and PHP code which is then
passed into the QA phase where it's run on a replica of the production
environment.

My goal is to allow my developers to work on the platform they know (MS),
using as many of the aspects of the production environment as possible (JVM
version, PHP version, and hopefully database version), without needing to
buy each new developer two machines, and incur the overhead of them
familiarising themselves with a flavour of Unix.

You could try out VMWare and run a linux virtual machine under Windows,
You could set it up once with all necessary servers and then copy the
files to each new developers machine.

VMWare is not free, but should be significantly cheaper than buying a
whole computer.

-------------
Hannu

D'Arcy,

In production the database servers are seperate multi-processor machines
with mirrored disks linked via Gigabit ethernet to the app server.

In development I have people extremely familiar with MS, but not very hot
with Unix in any flavour, who are developing Java and PHP code which is then
passed into the QA phase where it's run on a replica of the production
environment.

My goal is to allow my developers to work on the platform they know (MS),
using as many of the aspects of the production environment as possible (JVM
version, PHP version, and hopefully database version), without needing to
buy each new developer two machines, and incur the overhead of them
familiarising themselves with a flavour of Unix.

(from experience in a large .com web site)

Can you have a central DB server? Do all the dev DB servers need to be
independent? You could even have a machine w/ ip*(# developers) and bind
a postgresql to each ip for each developer (assuming you had enough
memory, etc).

We used oracle once upon a time at my .com and used seperate schemas for
the seperate developers. This may be tricky for your environment
because the developers would need to know what schema they would connect
to if all schemas were under the same pgsql instance.

- Brandon

----------------------------------------------------------------------------
c: 917-697-8665 h: 201-798-4983
b. palmer, bpalmer@crimelabs.net pgp:crimelabs.net/bpalmer.pgp5

On 27 Nov 2002, Hannu Krosing wrote:

Al Sutton kirjutas T, 26.11.2002 kell 20:37:

D'Arcy,

In production the database servers are seperate multi-processor machines
with mirrored disks linked via Gigabit ethernet to the app server.

In development I have people extremely familiar with MS, but not very hot
with Unix in any flavour, who are developing Java and PHP code which is then
passed into the QA phase where it's run on a replica of the production
environment.

My goal is to allow my developers to work on the platform they know (MS),
using as many of the aspects of the production environment as possible (JVM
version, PHP version, and hopefully database version), without needing to
buy each new developer two machines, and incur the overhead of them
familiarising themselves with a flavour of Unix.

You could try out VMWare and run a linux virtual machine under Windows,
You could set it up once with all necessary servers and then copy the
files to each new developers machine.

VMWare is not free, but should be significantly cheaper than buying a
whole computer.

If you're gonna go that far, look at reversing that situation, i.e. run a
linux box for each person with windows in vmware. It's a much more stable
situation than the other way around.

Either way, you can then run multiple Windows instances, of different
versions of windows if need be, which means you can test and develop for
multiple windows environments on one box, no rebooting, not even having to
turn your chair around.

VMWare likes memory, so get plenty if you go that way.

And don't worry about the problems getting familiar with most newer
flavors of linux, they're pretty easy to grok for most developers.

P.S. a note on windows and vmware: It's not uncommon for companies now to
build a large linux box, put vmware gsx on it, and run dozens of windows
instances. That way the spare cycles for one server can be used by
another, you can consolidate your windows servers onto a couple of boxen,
and you get much more reliable operation from windows when the hardware is
abstracted away from underneath it.

On Tue, 26 Nov 2002, bpalmer wrote:

D'Arcy,

In production the database servers are seperate multi-processor machines
with mirrored disks linked via Gigabit ethernet to the app server.

In development I have people extremely familiar with MS, but not very hot
with Unix in any flavour, who are developing Java and PHP code which is then
passed into the QA phase where it's run on a replica of the production
environment.

My goal is to allow my developers to work on the platform they know (MS),
using as many of the aspects of the production environment as possible (JVM
version, PHP version, and hopefully database version), without needing to
buy each new developer two machines, and incur the overhead of them
familiarising themselves with a flavour of Unix.

(from experience in a large .com web site)

Can you have a central DB server? Do all the dev DB servers need to be
independent? You could even have a machine w/ ip*(# developers) and bind
a postgresql to each ip for each developer (assuming you had enough
memory, etc).

We used oracle once upon a time at my .com and used seperate schemas for
the seperate developers. This may be tricky for your environment
because the developers would need to know what schema they would connect
to if all schemas were under the same pgsql instance.

From what the original post was saying, it looks more like they're working
on a smaller semi-embedded type thing, like a home database of cds or
something like that. OR at least something small like one or two people
would use like maybe a small inventory system or something.

High speed under heavy parallel access wasn't as important as good speed
for one or two users for this application.

scott.marlowe kirjutas K, 27.11.2002 kell 01:40:

On 27 Nov 2002, Hannu Krosing wrote:

You could try out VMWare and run a linux virtual machine under Windows,
You could set it up once with all necessary servers and then copy the
files to each new developers machine.

VMWare is not free, but should be significantly cheaper than buying a
whole computer.

If you're gonna go that far, look at reversing that situation, i.e. run a
linux box for each person with windows in vmware. It's a much more stable
situation than the other way around.

That's how I use it.

It's also nice way to try out new win software - install it, check it
out and if you don't like it just say no to "save changes?" when closing
the vmware session ;)

Either way, you can then run multiple Windows instances, of different
versions of windows if need be, which means you can test and develop for
multiple windows environments on one box, no rebooting, not even having to
turn your chair around.

VMWare likes memory, so get plenty if you go that way.

And don't worry about the problems getting familiar with most newer
flavors of linux, they're pretty easy to grok for most developers.

P.S. a note on windows and vmware: It's not uncommon for companies now to
build a large linux box, put vmware gsx on it, and run dozens of windows
instances. That way the spare cycles for one server can be used by
another, you can consolidate your windows servers onto a couple of boxen,
and you get much more reliable operation from windows when the hardware is
abstracted away from underneath it.

I guess this would be good for win _servers_, but how would you use this
setup for developers - will they all sit around a single box ?

---------------
Hannu

On 27 Nov 2002, Hannu Krosing wrote:

scott.marlowe kirjutas K, 27.11.2002 kell 01:40:

On 27 Nov 2002, Hannu Krosing wrote:

You could try out VMWare and run a linux virtual machine under Windows,
You could set it up once with all necessary servers and then copy the
files to each new developers machine.

VMWare is not free, but should be significantly cheaper than buying a
whole computer.

If you're gonna go that far, look at reversing that situation, i.e. run a
linux box for each person with windows in vmware. It's a much more stable
situation than the other way around.

That's how I use it.

It's also nice way to try out new win software - install it, check it
out and if you don't like it just say no to "save changes?" when closing
the vmware session ;)

Plus, it's real easy to back up your windows servers. just shut them
down, backup their image, and start them back up.

P.S. a note on windows and vmware: It's not uncommon for companies now to
build a large linux box, put vmware gsx on it, and run dozens of windows
instances. That way the spare cycles for one server can be used by
another, you can consolidate your windows servers onto a couple of boxen,
and you get much more reliable operation from windows when the hardware is
abstracted away from underneath it.

I guess this would be good for win _servers_, but how would you use this
setup for developers - will they all sit around a single box ?

You could probably use xwindows remote sessions for something like that,
but yeah, I was strictly thinking servers at that point. :-)

There is some work being done to put mutiple video cards and keyboard/mice
onto a single large box and share it though. I don't think I like taking
sharing quite that far though. :-0

The problem I have with VMWare is that for the cost of a licence plus the
additional hardware on the box running it (CPU power, RAM, etc.) I can buy a
second cheap machine, using VMWare doesn't appear to save me my biggest
overheads of training staff on Unix and cost of equipment (software and
hardware). I've been looking at Bochs, but 1.4.1 wasn't stable enough to
install RedHat, PostgreSQL, etc. reliably.

The database in question holds order information for over 2000 other
companies, and is growing daily. There is also a requirement to keep the
data indefinatley.

The developers are developing two things;

1- Providing an interface for the companies employees to update customer
information and answer customer queries.

2- Providing an area for merchants to log into that allows them to generate
some standardised reports over the order data, change passwords, setup
repeated payment system, etc.

Developing these solutions does include the possibilities of modify the
database schema, the configuration of the database, and the datatypes used
to represent the data (e.g. representing encyrpted data as a Base64 string
or blob), and therefore the developers may need to make fundamental changes
to the database and perform metrics on how they have affected performance.

Hope this helps,

Al.

----- Original Message -----
From: "scott.marlowe" <scott.marlowe@ihs.com>
To: "bpalmer" <bpalmer@crimelabs.net>
Cc: "D'Arcy J.M. Cain" <darcy@druid.net>; <pgsql-hackers@postgresql.org>
Sent: Tuesday, November 26, 2002 9:13 PM
Subject: Re: [mail] Re: [HACKERS] Native Win32 sources

On Tue, 26 Nov 2002, bpalmer wrote:

D'Arcy,

In production the database servers are seperate multi-processor

machines

with mirrored disks linked via Gigabit ethernet to the app server.

In development I have people extremely familiar with MS, but not

very hot

with Unix in any flavour, who are developing Java and PHP code which

is then

passed into the QA phase where it's run on a replica of the

production

environment.

My goal is to allow my developers to work on the platform they know

(MS),

using as many of the aspects of the production environment as

possible (JVM

version, PHP version, and hopefully database version), without

needing to

buy each new developer two machines, and incur the overhead of them
familiarising themselves with a flavour of Unix.

(from experience in a large .com web site)

Can you have a central DB server? Do all the dev DB servers need to be
independent? You could even have a machine w/ ip*(# developers) and

bind

a postgresql to each ip for each developer (assuming you had enough
memory, etc).

We used oracle once upon a time at my .com and used seperate schemas for
the seperate developers. This may be tricky for your environment
because the developers would need to know what schema they would connect
to if all schemas were under the same pgsql instance.

From what the original post was saying, it looks more like they're

working

On 27 Nov 2002 at 8:21, Al Sutton wrote:

The problem I have with VMWare is that for the cost of a licence plus the
additional hardware on the box running it (CPU power, RAM, etc.) I can buy a
second cheap machine, using VMWare doesn't appear to save me my biggest
overheads of training staff on Unix and cost of equipment (software and
hardware). I've been looking at Bochs, but 1.4.1 wasn't stable enough to
install RedHat, PostgreSQL, etc. reliably.

I have been reading this thread all along and I have some suggestions. They are
not any different than already made but just summerising them.

1) Move to linux.

You can put a second linux box with postgresql on it. Anyway your app. is on
windows so it does not make much of a difference because developers will be
accessing database from their machines.

Secondly if you buy a good enough mid-range machine, say with 40GB SCSI with 2G
of RAM, each developer can develop on his/her own database. In case of
performance testing, you can schedule it just like any other shared resource.

It is very easy to run multiple isolated postgresql instances on a linux
machine. Just change the port number and use a separate data directory. That's
it..

Getting people familiarized with unix/.linux upto a point where they can use
their own database is matter of half a day.

2) Do not bank too much on windows port yet.

Will all respect to people developing native windows port of postgresql, unless
you know the correct/stable behaviour of postgresql on unix, you might end up
in a situation where you don't know whether a bug/problem is in postgresql or
with postgresql/windows. I would not recommend getting into such a situation.

Your contribution is always welcome in any branch but IMO it is not worth at
the risk of slipping your own product development.

Believe me, moving to linux might seem scary at first but it is no more than
couple of days matter to get a box to play around. Untill you need a good
machine for performance tests, a simple 512MB machie with enough disk would be
sufficient for any development among the group..

HTH

Bye
Shridhar

--
My father taught me three things: (1) Never mix whiskey with anything but
water. (2) Never try to draw to an inside straight. (3) Never discuss business
with anyone who refuses to give his name.

On Wed, 2002-11-27 at 08:21, Al Sutton wrote:

The problem I have with VMWare is that for the cost of a licence plus the
additional hardware on the box running it (CPU power, RAM, etc.) I can buy a
second cheap machine, using VMWare doesn't appear to save me my biggest
overheads of training staff on Unix and cost of equipment (software and
hardware). I've been looking at Bochs, but 1.4.1 wasn't stable enough to
install RedHat, PostgreSQL, etc. reliably.

The database in question holds order information for over 2000 other
companies, and is growing daily. There is also a requirement to keep the
data indefinatley.

The developers are developing two things;

1- Providing an interface for the companies employees to update customer
information and answer customer queries.

2- Providing an area for merchants to log into that allows them to generate
some standardised reports over the order data, change passwords, setup
repeated payment system, etc.

Developing these solutions does include the possibilities of modify the
database schema, the configuration of the database, and the datatypes used
to represent the data (e.g. representing encyrpted data as a Base64 string
or blob), and therefore the developers may need to make fundamental changes
to the database and perform metrics on how they have affected performance.

If you need metrics and the production runs on some kind of unix, you
should definitely do the measuring on unix as well. A developers machine
with different os and other db tuning parameters may give you _very_
different results from the real deployment system.

Also, porting postgres to win32 wont magically make it into MS Access -
most DB management tasks will be exactly the same. If your developer are
afraid of command line, give them some graphical or web tool for
managing the db.

If they dont want to manage linux, then just set it up once and don't
give them the root pwd ;)

--------------
Hannu

Hannu,

Using a Win32 platform will allow them to perform relative metrics. I'm not
looking for a statement saying things are x per cent faster than production,
I'm looking for reproducable evidence that an improvement offers y per cent
faster performance than another configuration on the same platform.

The QA environment is designed to do final testing and compiling definitive
metrics against production systems, what I'm looking for is an easy method
of allowing developers to see the relative change on performance for a given
change on the code base.

I'm fully aware that they'll still have to use the config files of
PostgreSQL on a Win32 port, but the ability to edit the config files, modify
sql dumps to load data into new schema, transfer files between themselves,
and perform day to day tasks such as reading Email and MS-Word formatted
documents sent to us using tools that they are currently familiar with is a
big plus for me.

The bottom line is I can spend money training my developers on Linux and
push project deadlines back until they become familiar with it, or I can
obtain a free database on their native platform and reduce the number of
machines needed per developer as well as making the current DB machines
available as the main machine for new staff. The latter makes the most sense
in the profit based business environment which I'm in.

Al.

----- Original Message -----
From: "Hannu Krosing" <hannu@tm.ee>
To: "Al Sutton" <al@alsutton.com>
Cc: "scott.marlowe" <scott.marlowe@ihs.com>; "bpalmer"
<bpalmer@crimelabs.net>; <pgsql-hackers@postgresql.org>
Sent: Wednesday, November 27, 2002 10:54 AM
Subject: [spam] Re: [mail] Re: [HACKERS] Native Win32 sources

On Wed, 2002-11-27 at 08:21, Al Sutton wrote:

The problem I have with VMWare is that for the cost of a licence plus

the

additional hardware on the box running it (CPU power, RAM, etc.) I can

buy a

second cheap machine, using VMWare doesn't appear to save me my biggest
overheads of training staff on Unix and cost of equipment (software and
hardware). I've been looking at Bochs, but 1.4.1 wasn't stable enough to
install RedHat, PostgreSQL, etc. reliably.

The database in question holds order information for over 2000 other
companies, and is growing daily. There is also a requirement to keep the
data indefinatley.

The developers are developing two things;

1- Providing an interface for the companies employees to update customer
information and answer customer queries.

2- Providing an area for merchants to log into that allows them to

generate

some standardised reports over the order data, change passwords, setup
repeated payment system, etc.

Developing these solutions does include the possibilities of modify the
database schema, the configuration of the database, and the datatypes

used

to represent the data (e.g. representing encyrpted data as a Base64

string

or blob), and therefore the developers may need to make fundamental

changes

to the database and perform metrics on how they have affected

performance.

I've posted an Email to the list as to why I'm avoiding a move to linux
(cost of training -v- cost of database (free) + money saved from recycling
current DB machines).

My experience with PostgreSQL has always been good, and I beleive that we
can test any potential bugs that we may beleive are in the database by
running our app in our the QA environment against the Linux version of the
database (to test platform specifics), and then the database version in
production (to test version specifics).

I'm quite happy to spend the time doing this to gain the cost benefit of
freeing up the extra machines my developers currently have.

Al.

----- Original Message -----
From: "Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>
To: <pgsql-hackers@postgresql.org>
Sent: Wednesday, November 27, 2002 8:41 AM
Subject: Re: [mail] Re: [HACKERS] Native Win32 sources

On 27 Nov 2002 at 8:21, Al Sutton wrote:

The problem I have with VMWare is that for the cost of a licence plus

the

additional hardware on the box running it (CPU power, RAM, etc.) I can

buy a

second cheap machine, using VMWare doesn't appear to save me my biggest
overheads of training staff on Unix and cost of equipment (software and
hardware). I've been looking at Bochs, but 1.4.1 wasn't stable enough to
install RedHat, PostgreSQL, etc. reliably.

I have been reading this thread all along and I have some suggestions.

They are

not any different than already made but just summerising them.

1) Move to linux.

You can put a second linux box with postgresql on it. Anyway your app. is

on

windows so it does not make much of a difference because developers will

be

accessing database from their machines.

Secondly if you buy a good enough mid-range machine, say with 40GB SCSI

with 2G

of RAM, each developer can develop on his/her own database. In case of
performance testing, you can schedule it just like any other shared

resource.

It is very easy to run multiple isolated postgresql instances on a linux
machine. Just change the port number and use a separate data directory.

That's

it..

Getting people familiarized with unix/.linux upto a point where they can

use

their own database is matter of half a day.

2) Do not bank too much on windows port yet.

Will all respect to people developing native windows port of postgresql,

unless

you know the correct/stable behaviour of postgresql on unix, you might end

up

in a situation where you don't know whether a bug/problem is in postgresql

or

with postgresql/windows. I would not recommend getting into such a

situation.

Your contribution is always welcome in any branch but IMO it is not worth

at

the risk of slipping your own product development.

Believe me, moving to linux might seem scary at first but it is no more

than

couple of days matter to get a box to play around. Untill you need a good
machine for performance tests, a simple 512MB machie with enough disk

would be

sufficient for any development among the group..

HTH

Bye
Shridhar

--
My father taught me three things: (1) Never mix whiskey with anything but
water. (2) Never try to draw to an inside straight. (3) Never discuss

business

On Wed, 27 Nov 2002, Al Sutton wrote:

Hannu,

Using a Win32 platform will allow them to perform relative metrics. I'm not
looking for a statement saying things are x per cent faster than production,
I'm looking for reproducable evidence that an improvement offers y per cent
faster performance than another configuration on the same platform.

So, does cygwin offer any win? I know it's still "unix on windows" but
it's the bare minimum of unix, and it is easy to create one image of an
install and copy it around onto other boxes in a semi-ready to go format.

It's an option, but I can see it being a bit of an H-Bomb to kill an ant if
the Win32 source appears within the next 6 weeks.

I've played used cygwin before and I've always been uncomfortable with the
way it's integrated with Windows. It always came accross as something that
isn't really for the windows masses, but more for techies who want Unix on
an MS platform. My main dislikes about it are;

- Changing paths. If my developers install something in c:\temp they expect
to find it under /temp on cygwin.

- Duplicating home directories. The users already have a home directory
under MS, why does cygwin need to use a different location?

My current plan is to use the Win32 native port myself when it first appears
and thrash our app against it. Once I'm happy that the major functionality
of our app works against the Win32 port, I'll introduce it to a limited
number of developers who enjoy hacking code if it goes wrong and get them to
note a log any problems the come accross.

If nothing else it should mean a few more bodies testing the Win32 port
(although I expect you'll find they'll be a large number of those as soon as
it hits CVS).

Al.

----- Original Message -----
From: "scott.marlowe" <scott.marlowe@ihs.com>
To: "Al Sutton" <al@alsutton.com>
Cc: "Hannu Krosing" <hannu@tm.ee>; "bpalmer" <bpalmer@crimelabs.net>;
<pgsql-hackers@postgresql.org>
Sent: Wednesday, November 27, 2002 11:08 PM
Subject: Re: [spam] Re: [mail] Re: [HACKERS] Native Win32 sources

On Wed, 27 Nov 2002, Al Sutton wrote:

Hannu,

Using a Win32 platform will allow them to perform relative metrics. I'm

not

looking for a statement saying things are x per cent faster than

production,

I'm looking for reproducable evidence that an improvement offers y per

cent