Thread: Native Win32 sources
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
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, Pennsylvania19073
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, Pennsylvania19073
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 > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org >
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 currentlyhave an M$-Windows box and a> Linux box each in order to allow them to read M$-Office documents sent to us> anddevelop against PostgreSQL (which we use in production).> > I know I could have a shared Linux box with multiple databasesand have them> bind to that, but one of the important aspects of our application is> response time, and you can'taccurately measure response times for code> changes on a shared system.> > Having a Win32 native version would savea 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 sendme a copy of the sources?> >> > Oh, you are probably asking about the sources. They are not publically> > availableyet.
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 > > > available yet. >
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
> 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.
>
> ---------------------------(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
>
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, Pennsylvania19073
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-4983b. 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.
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 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.
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 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. > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
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 ByeShridhar -- 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. > > 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 > > > >
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 > with anyone who refuses to give his name. > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
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 > > 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. > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster