Well, when you have 2.7 million records in a database, the code might be
as good
as it can be.
I have recoverd the performance lost when I moved to Postgres 7.0 by
executing
SET enable_indexscan = OFF before creating my cursors and turning it back on
for the inner loop query. It may even be
I have set index_scan off for tomorrow morning's run. I will let you know
what happens.
I think my problem is fixed. By disabling index scan while creating the
cursors and then turning it back on again for the small query that occurs in
my inner loop the performance has returned to normal
"Bryan White" [EMAIL PROTECTED] writes:
I have recoverd the performance lost when I moved to Postgres 7.0 by
executing SET enable_indexscan = OFF before creating my cursors and
turning it back on for the inner loop query. It may even be faster
then before so I am happy.
OK, so it was the
"Bryan White" [EMAIL PROTECTED] writes:
I have recoverd the performance lost when I moved to Postgres 7.0 by
executing SET enable_indexscan = OFF before creating my cursors and
turning it back on for the inner loop query. It may even be faster
then before so I am happy.
OK, so it was
I have a large report that I run once a day. Under 6.5.3 it took just over
3hrs to run. Under 7.0 it is now taking 8 hours to run. No other changes
were made.
This is on RedHat Linux 6.2. A PIII 733 with 384MB Ram, and 2 IDE 7200 RPM
disks. One disk contains the Postgres directroy including
"Bryan White" [EMAIL PROTECTED] writes:
Top tells me the front end process is using 5 to 10 percent of the CPU and
the back end is using 10 to 20 percent. The load average is about 1.0 and
the CPU is about 80% idle.
It's probably waiting for disk I/O ...
What does EXPLAIN tell you about how
Try putting 'nofsync' in your pg_options.
Bryan White wrote:
I have a large report that I run once a day. Under 6.5.3 it took just over
3hrs to run. Under 7.0 it is now taking 8 hours to run. No other changes
were made.
This is on RedHat Linux 6.2. A PIII 733 with 384MB Ram, and 2
