[EMAIL PROTECTED] ("John Wells") writes: > To that end, I've also started studying up on Postgresql. It seems to > have all the necessary features for a transaction heavy DB. The recent > release is 7.3. Of course, "the proof will be in the pudding." We > average 2.5 million transactions per day or 800 per second. > Unfortunately, we would have no way of testing that until we committed to > getting the business logic moved over and had something to test it with. > This is a bit of a "catch 22" situation. Just wished I knew of someone > locally who was running Postgresql in such a heavy environment. I'd love > to find out how it performs for them. -----------
The killer question is of what exactly it is that is being done 800 times per second. I have seen PostgreSQL handling tens of millions of "things" per day, when those things are relatively small and non-interacting. If most of the 800 are read-only, then that seems not at all frightening. If the activity is update-heavy, with complex interactions, then the "level of challenge" goes up, irrespective of what database system you plan on using. It would seem surprising for a well-run PostgreSQL site to not be quite readily as capable as Progress on similar hardware, but it is not a trivial task to verify that with something resembling your kind of transaction load. What you, in effect, need to do is to construct a prototype and see how it holds up under load. That's a nontrivial amount of work, irrespective of the database in use. I think you'll need to construct that prototype, perhaps as a set of scripted "clients" that you can spawn to hammer at your "server." A wise approach is to write this in a somewhat generic fashion so that you can try it out on several different databases. Or so that you can at least express, to management, the possibility of doing so :-). Question: What kind of hardware are you using for the present system? -- output = reverse("ofni.smrytrebil" "@" "enworbbc") <http://dev6.int.libertyrms.com/> Christopher Browne (416) 646 3304 x124 (land) ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org