In 2003 I met this guy who was doing Computation Fluid Dynamics and he had to
use this software written by physics engineers in FORTRAN. 1 Gig of ram wasn't
yet the standard for a desktop pc at that time but the software required at
least 1 Gig just to get started. So I thought what is the
--- On Mon, 11/8/08, Gregory Stark [EMAIL PROTECTED] wrote:
From: Gregory Stark [EMAIL PROTECTED]
Subject: Re: [PERFORM] Using PK value as a String
To: Jay [EMAIL PROTECTED]
Cc: pgsql-performance@postgresql.org
Date: Monday, 11 August, 2008, 10:30 AM
Jay [EMAIL PROTECTED] writes:
I have
I am guessing that you are using DELETE to remove the 75,000 unimportant.
Change your batch job to CREATE a new table consisting only of the 5,000
important. You can use CREATE TABLE table_name AS select_statement command.
Then drop the old table. After that you can use ALTER TABLE to change the
Thanks Guys, this is really useful, especially the pg_service.conf. I have got
an app where the connection parameters have to be set in 3 different places I
was thinking of writing something myself but now that I know of
pg_service.conf, problem solved.
Regards,
Val
--- On Tue, 22/7/08,
Thanks to everyone who replied. There were some really good points.
However, I found what is causing the difference. The perl program was
connecting to the database via a TCP socket while the C version was using Unix
socket. I changed the connect in my perl script, so that it now uses Unix
Hi,
I have ran quite a few tests comparing how long a query takes to execute from
Perl/DBI as compared to psql/pqlib. No matter how many times I run the test the
results were always the same.
I run a SELECT all on a fairly big table and enabled the
log_min_duration_statement option. With psql
HI,
I have an application that maintains 150 open connections to a Postgres DB
server. The application works fine without a problem for the most time.
The problem seem to arise when a SELECT that returns a lot of rows is executed
or the SELECT is run on a large object. These selects are run
