On Thu, 2006-11-09 at 10:16 +0000, Richard Huxton wrote: > Bill wrote: > > Jorge Godoy wrote: > > > >> I have the impression that you're missing a lot of sections in the > >> manual... How about some time to re-read it? > > > > I don't know about you but for me a 1500 page manual is at least two > > weeks of full time reading.<g> I have read several sections of it but I > > am trying to decide if PostgreSQL should be considered for a project > > and I don't have 80 hours to make the evaluation. > > If you don't have 80 hours to evaluate a new database, I'd suggest > sticking with whatever you're already familiar with. You only have to > hit a couple of minor problems with your implementation to consume more > than 80 hours. If you're up against timescales that short, then stick to > technologies you already know front-to-back. > If we turn away everyone who was "trying to decide if PostgreSQL should be considered", I think that we're failing in the advocacy department. It may be just a preliminary analysis to see which databases claim to meet the application's requirements. Perhaps he doesn't already have a team of DBAs that know any RDBMS front-to-back. I think he should consider PostgreSQL, and try to find out if it is a possible solution for his application. Asking questions on -general or IRC, in addition to googling the docs, are probably the best way to get answers to his questions quickly. It took me a long time before I really understood where to find things in the docs very quickly*. And just like mathematics, sometimes asking the question out loud answers itself :) However, you're right. If Bill is already familiar with one product, it's probably a mistake to jump blind into any new RDBMS on an important project; and that includes the world's most advanced open source database. He should see if it looks good, then evaluate and test it as thoroughly as he would any other RDBMS. Regards, Jeff Davis * The docs are great, but it's a complex subject, everything's inter- related, and the words you're looking for aren't always obvious.
