-----BEGIN PGP SIGNED MESSAGE-----
Justin Davis wrote:
| I have five PC's accessing a PG database that is mounted on a
| Dell Windows 2003 server. The PC's are accessing the database with a
| Fujitsu cobol program via ODBC (all machines have same (newest) ODBC
| driver from PG). 2 of the machines are the newest I have and both
| pretty identically configured but are very slow by comparison to the
| others. My colleagues and I are still in the exploration / decision
| process, we have been working with and learning the database about 2
| I'm looking to see if anyone knows of O/S or hardware issues right off
| the bat or can recommend a debug method, log checking, etc. path we
| might follow.
| The program in question reads the PG database and displays matching
| query results on a cobol screen, for the point of this topic that is all
| it is doing. We run the same query from each PC which returns 15
| records out of a 6,000 record customer DB.
| The machines:
| - 2 are 2.0 Ghz Dells with 512 Ram & XP SP2 - they take just over 2
| - 1 AMD 2.4 with 256 Ram & XP SP2 - just under 2 secs.
| - 1 AMD 900 Mhz with 256 Ram & XP SP 1 - just under 2 secs
| - 1 Intel 266 Mhz with 256 Ram & Windows 2000 - 11-13 secs
While re-reading your post, I was (still) under the impression that
those machines are all client machines and that there is only one
database they are all accessing. Is my impression true?
If so, then I'm afraid there must be some other issue you've been
hitting, because from the viewpoint of a postmaster, it is completely
irrelevant who the client is. Unless so, can you please provide some
evidence that the issue at hand really has to do with the PostgreSQL
query shipping to those Dells (profiling, for example), so we have
something to work from?
My assertion though is that there's either an issue in the ODBC layer,
or the COBOL program you're running (be it your code or the runtime).
While at it, and completely unrelated, I'm not sure that, both from the
performance and reliability viewpoint, running production PostgreSQL on
a Windows machine may be the best possible decision. If you have the
luxury of experimenting, and unless your side-goal is to run-proof the
Windows version of PostgreSQL, I'd suggest you try a couple of
alternatives, such as Linux, BSD or even Solaris, whichever you feel
will offer you better future support.
If you choose to run it on Windows afterall, I'd kindly advise you to do
your best to stay on the safe side of the story with a double-checked
backup strategy, solely because the Windows version of PostgreSQL is a
new product and not widely used in production environments, so there is
not much expertise yet in the specifics of keeping it performant, stable
and most of all, how to tackle things after the worst has happened.
gregab at p0f dot net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
-----END PGP SIGNATURE-----