From: | David Jarvis <thangalin(at)gmail(dot)com> |
---|---|
To: | Bryan Hinton <bryan(at)bryanhinton(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Random Page Cost and Planner |
Date: | 2010-05-28 03:29:13 |
Message-ID: | AANLkTil9JM68TEFsm8s5ZhJKrmmr1X-SqfEHb-5kxQ8d@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi, Bryan.
Thanks for the notes. I thought about using a prepared statement, but I
cannot find any examples of using a PREPARE statement from within a
function, and don't really feel like tinkering around to figure it out.
Performance is at the point where the Java/PHP bridge and JasperReports are
bottlenecks. The run_time variable seldom goes beyond 2.6s now. The reports
take about 5 - 6 seconds to appear. At this point I'm into diminishing
returns.
I can perform a 60-minute hardware upgrade or spend 12 hours profiling to
get less than the same net effect (and there is no guarantee I can improve
the performance in fewer than 12 hours -- it took me 17 days and countless
e-mails to this mailing group just to get this far -- *thank you again for
all the help*, by the way). (If I was a PostgreSQL guru like most people on
this list, it might take me 2 hours of profiling to optimize away the
remaining bottlenecks, but even then the gain would only be a second or two
in the database arena; the other system components will also gain by a
hardware upgrade.)
Dave
From | Date | Subject | |
---|---|---|---|
Next Message | 黄永卫 | 2010-05-28 04:11:31 | 答复: [PERFORM] About Tom Lane's Xeon CS test case |
Previous Message | Tom Lane | 2010-05-28 02:56:12 | Re: merge join killing performance |