Re: Jdbc/postgres performance - Mailing list pgsql-performance
From | Rohit_Behl |
---|---|
Subject | Re: Jdbc/postgres performance |
Date | |
Msg-id | 407937EC76157D439EB0C9F9B6047EFD40017E@BLRKECMSG04.ad.infosys.com Whole thread Raw |
In response to | Jdbc/postgres performance ("Rohit_Behl" <Rohit_Behl@infosys.com>) |
Responses |
Re: Jdbc/postgres performance
|
List | pgsql-performance |
Hi I made the following changes to the conf file: enable_indexscan = true enable_seqscan = false We also have a large amount of data being inserted into our tables. I was just wondering if this could have an impact onthe inserts since I guess this change is on the database. Please let me know. Thanks Regards Rohit ________________________________ From: Rohit_Behl Sent: Wed 18/10/2006 11:10 To: Merlin Moncure Cc: pgsql-performance@postgresql.org Subject: Re: [PERFORM] Jdbc/postgres performance Hi Merlin I have disabled seq-scan and now it works like a charm. Thanks it was a saver. Regards Rohit On 10/18/06, Bucky Jordan <bjordan@lumeta.com> wrote: > > On 10/17/06, Rohit_Behl <Rohit_Behl@infosys.com> wrote: > > > Select events.event_id, ctrl.real_name, events.tsds, events.value, > > events.lds, events.correction, ctrl.type, ctrl.freq from table > > events, iso_midw_control ctrl where events.obj_id = ctrl.obj_id and > > events.event_id > ?::bigint order by events.event_id limit ? > > > After a quick search on the JDBC list, it looks like there's some > recent discussion on the subject of how to give the planner better > insight for prepared statements (the subject is "Blind Message" if > you're looking...). > > So, I'm off to go read there and perhaps join the jdbc mailing list too. this is not really a jdbc issue, just a practical problem with prepared statements...except for the mechanism if any thejdbc driver allows you to choose if a statement is prepared. > But, a more general postgres question. I assume if I want to turn > prepared statements off altogether (say I'm using a jdbc abstraction you turn off prepared statements by not invoking sql prepare or PQprepare. (or, if jdbc implements its own protocol client,it's version of PQprepare). > layer that likes parameterized statements, and there's other benefits > to parameterizing other than just saving on db parse/plan) can I set > max_prepared_transactions to 0? Is there any other option outside of this setting is for 2pc and is not relevent to the discussion :) even if it were, im not so sure about a setting designedto enforce a partcular method of querying. yes, you are correct this is not exactly the use case for hints being discussed in -hackers. however, imho, this is muchmore important and relevant so long as prepared statements continue to work the way they do. merlin **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you arenot the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not tocopy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mailmay contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for anydamage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before openingthe e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to orfrom this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS***
pgsql-performance by date: