Re: [PERFORM] select on 22 GB table causes "An I/O error occured while sending to the backend." exception

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 probl

Re: [PERFORM] Using PK value as a String

--- 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]> w

Re: [PERFORM] Database size Vs performance degradation

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 th

Re: [PERFORM] Perl/DBI vs Native

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, Jeffr

Re: [PERFORM] Perl/DBI vs Native

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 sock

[PERFORM] Perl/DBI vs Native

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

[PERFORM] postgres overall performance seems to degrade when large SELECT are requested

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 fr