| From: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
|---|---|
| To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
| Cc: | Rohit_Behl <Rohit_Behl(at)infosys(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Jdbc/postgres performance |
| Date: | 2006-10-18 13:20:54 |
| Message-ID: | b42b73150610180620g256ba45fp1238afcae6f74c45@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 10/18/06, Heikki Linnakangas <heikki(at)enterprisedb(dot)com> wrote:
> I would suggest using setting "prepareThreshold=0" in the JDBC driver
> connection URL, or calling pstmt.setPrepareThreshold(0) in the
> application. That tells the driver not to use server-side prepare, and
> the query will be re-planned every time you execute it with the real
> values of the parameters.
that works. I think another alternative is to just turn off seqscan
temporarily for the session:
set enable_seqscan=false;
and re-enable it after prepareing the statement. however I agree that
seqscan should be enabled for normal operation. in fact, this becomes
more and more important as your database becomes really big due to
poor random i/o of hard drives.
merlin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2006-10-18 13:31:41 | Re: Jdbc/postgres performance |
| Previous Message | Heikki Linnakangas | 2006-10-18 12:51:47 | Re: Jdbc/postgres performance |