Skip site navigation (1) Skip section navigation (2)

Re: Jdbc/postgres performance

From: "Rohit_Behl" <Rohit_Behl(at)infosys(dot)com>
To: "Rohit_Behl" <Rohit_Behl(at)infosys(dot)com>,"Merlin Moncure" <mmoncure(at)gmail(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Jdbc/postgres performance
Date: 2006-10-18 11:58:29
Message-ID: 407937EC76157D439EB0C9F9B6047EFD40017E@BLRKECMSG04.ad.infosys.com (view raw or flat)
Thread:
Lists: 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 on the 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(at)postgresql(dot)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(at)lumeta(dot)com> wrote:

> > On 10/17/06, Rohit_Behl <Rohit_Behl(at)infosys(dot)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 the jdbc 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 designed to 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 much more 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 are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from 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***

In response to

Responses

pgsql-performance by date

Next:From: Arnaud LesauvageDate: 2006-10-18 12:12:29
Subject: Re: Index on two columns not used
Previous:From: Heikki LinnakangasDate: 2006-10-18 11:40:05
Subject: Re: Index on two columns not used

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group