pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedJdbc/postgres performance
12+ messages / 7 participants
[nested] [flat]
* Jdbc/postgres performance
@ 2006-10-17 19:05 Behl, Rohit (Infosys) <Rohit.Behl@uk.bp.com>
0 siblings, 1 reply; 12+ messages in thread
From: Behl, Rohit \(Infosys\) @ 2006-10-17 19:05 UTC (permalink / raw)
To: pgsql-performance
Hi
We are facing performance problems in postgres while executing a query.
When I execute this query on the server it takes 5-10 seconds. Also I
get good performance while executing this query from my code in java
with the hard codes values. I face severe performance problems when I
run it using a prepared statement.
The query is as follows:
Select events.event_id, ctrl.real_name, events.tsds, events.value,
events.lds, events.correction, ctrl.type, ctrl.freq from
iso_midw_data_update_events events, iso_midw_control ctrl where
events.obj_id = ctrl.obj_id and events.event_id > 68971124 order by
events.event_id limit 2000
The above query executes in 5-10 seconds.
However the below query executes in 8 mins:
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 ?
setLong(1, 68971124);
setInt(2, 2000);
The table has close to 5 million rows. The table has the following
index:
iso_midw_data_update_events_event_id_key
iso_midw_data_update_events_lds_idx
iso_midw_data_update_events_obj_id_idx
The table is described as follows:
Columns_name data_type type_name column_size
lds 2 numeric 13
obj_id 2 numeric 6
tsds 2 numeric 13
value 12 varchar 22
correction 2 numeric 1
delta_lds_tsds 2 numeric 13
event_id -5 bigserial 8
Please tell me what I am missing while setting the prepared statement. I
am using postgres7.4.2. and postgresql-8.1-407.jdbc3.jar.
Thanks
Regards
Rohit
^ permalink raw reply [nested|flat] 12+ messages in thread
* Jdbc/postgres performance
@ 2006-10-17 19:45 Rohit_Behl <Rohit_Behl@infosys.com>
0 siblings, 1 reply; 12+ messages in thread
From: Rohit_Behl @ 2006-10-17 19:45 UTC (permalink / raw)
To: pgsql-performance
Hi
We are facing performance problems in postgres while executing a query. When I execute this query on the server it takes 5-10 seconds. Also I get good performance while executing this query from my code in java with the hard codes values. I face severe performance problems when I run it using a prepared statement.
The query is as follows:
Select events.event_id, ctrl.real_name, events.tsds, events.value, events.lds, events.correction, ctrl.type, ctrl.freq from iso_midw_data_update_events events, iso_midw_control ctrl where events.obj_id = ctrl.obj_id and events.event_id > 68971124 order by events.event_id limit 2000
The above query executes in 5-10 seconds.
However the below query executes in 8 mins:
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 ?
setLong(1, 68971124);
setInt(2, 2000);
The table has close to 5 million rows. The table has the following index:
iso_midw_data_update_events_event_id_key
iso_midw_data_update_events_lds_idx
iso_midw_data_update_events_obj_id_idx
The table is described as follows:
Columns_name data_type type_name column_size
lds 2 numeric 13
obj_id 2 numeric 6
tsds 2 numeric 13
value 12 varchar 22
correction 2 numeric 1
delta_lds_tsds 2 numeric 13
event_id -5 bigserial 8
Please tell me what I am missing while setting the prepared statement. I am using postgres7.4.2. and postgresql-8.1-407.jdbc3.jar.
Thanks
Regards
Rohit
**************** 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***
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Jdbc/postgres performance
@ 2006-10-17 20:28 Merlin Moncure <mmoncure@gmail.com>
parent: Rohit_Behl <Rohit_Behl@infosys.com>
0 siblings, 1 reply; 12+ messages in thread
From: Merlin Moncure @ 2006-10-17 20:28 UTC (permalink / raw)
To: Rohit_Behl <Rohit_Behl@infosys.com>; +Cc: pgsql-performance
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 ?
unfortunately parameterized limit statements cause problems due to the
fact the planner has a hard coded 'guess' of 10% of rows returned when
the plan is generated. I mention this everyime query hints proposal
comes up :-).
best you can do is to try turning off seqscan and possibly bitmap scan
when the plan is generated.
merlin
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Jdbc/postgres performance
@ 2006-10-18 00:47 Bucky Jordan <bjordan@lumeta.com>
parent: Merlin Moncure <mmoncure@gmail.com>
0 siblings, 1 reply; 12+ messages in thread
From: Bucky Jordan @ 2006-10-18 00:47 UTC (permalink / raw)
To: Merlin Moncure <mmoncure@gmail.com>; Rohit_Behl <Rohit_Behl@infosys.com>; +Cc: pgsql-performance
> -----Original Message-----
> From: pgsql-performance-owner@postgresql.org
[mailto:pgsql-performance-
> owner@postgresql.org] On Behalf Of Merlin Moncure
> Sent: Tuesday, October 17, 2006 4:29 PM
> To: Rohit_Behl
> Cc: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Jdbc/postgres performance
>
> 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 ?
>
> unfortunately parameterized limit statements cause problems due to the
> fact the planner has a hard coded 'guess' of 10% of rows returned when
> the plan is generated. I mention this everyime query hints proposal
> comes up :-).
I'm not sure that this has anything to do with hints (yes, I know hints
are a popular topic as of late..) but from the 8.1 Manual:
"This is because when the statement is planned and the planner attempts
to determine the optimal query plan, the actual values of any parameters
specified in the statement are unavailable."
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.
But, a more general postgres question. I assume if I want to turn
prepared statements off altogether (say I'm using a jdbc abstraction
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
JDBC? (I'll be moving my other questions over to the JDBC list...)
Also, others might be interested in the JDBC documentation, which is
separate from the main Postgres manual and can be found at:
http://jdbc.postgresql.org/documentation/
- Bucky
> best you can do is to try turning off seqscan and possibly bitmap scan
> when the plan is generated.
>
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Jdbc/postgres performance
@ 2006-10-18 03:41 Merlin Moncure <mmoncure@gmail.com>
parent: Bucky Jordan <bjordan@lumeta.com>
0 siblings, 1 reply; 12+ messages in thread
From: Merlin Moncure @ 2006-10-18 03:41 UTC (permalink / raw)
To: Bucky Jordan <bjordan@lumeta.com>; +Cc: Rohit_Behl <Rohit_Behl@infosys.com>; pgsql-performance
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 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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Jdbc/postgres performance
@ 2006-10-18 05:19 Tom Lane <tgl@sss.pgh.pa.us>
parent: Merlin Moncure <mmoncure@gmail.com>
0 siblings, 1 reply; 12+ messages in thread
From: Tom Lane @ 2006-10-18 05:19 UTC (permalink / raw)
To: Merlin Moncure <mmoncure@gmail.com>; +Cc: Bucky Jordan <bjordan@lumeta.com>; Rohit_Behl <Rohit_Behl@infosys.com>; pgsql-performance
"Merlin Moncure" <mmoncure@gmail.com> writes:
> this is not really a jdbc issue, just a practical problem with
> prepared statements...
Specifically, that the OP is running a 7.4 backend, which was our
first venture into prepared parameterized statements. PG 8.1 will
do better, 8.2 should do better yet.
regards, tom lane
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Jdbc/postgres performance
@ 2006-10-18 10:10 Rohit_Behl <Rohit_Behl@infosys.com>
0 siblings, 1 reply; 12+ messages in thread
From: Rohit_Behl @ 2006-10-18 10:10 UTC (permalink / raw)
To: Merlin Moncure <mmoncure@gmail.com>; +Cc: pgsql-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 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***
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Jdbc/postgres performance
@ 2006-10-18 11:58 Rohit_Behl <Rohit_Behl@infosys.com>
parent: Rohit_Behl <Rohit_Behl@infosys.com>
0 siblings, 1 reply; 12+ messages in thread
From: Rohit_Behl @ 2006-10-18 11:58 UTC (permalink / raw)
To: Rohit_Behl <Rohit_Behl@infosys.com>; Merlin Moncure <mmoncure@gmail.com>; +Cc: 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@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 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***
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Jdbc/postgres performance
@ 2006-10-18 12:51 Heikki Linnakangas <heikki@enterprisedb.com>
parent: Rohit_Behl <Rohit_Behl@infosys.com>
0 siblings, 1 reply; 12+ messages in thread
From: Heikki Linnakangas @ 2006-10-18 12:51 UTC (permalink / raw)
To: Rohit_Behl <Rohit_Behl@infosys.com>; +Cc: Merlin Moncure <mmoncure@gmail.com>; pgsql-performance
Rohit_Behl wrote:
> 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.
enable_seqscan shouldn't affect plain inserts, but it will affect
*every* query in the system.
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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Jdbc/postgres performance
@ 2006-10-18 13:20 Merlin Moncure <mmoncure@gmail.com>
parent: Heikki Linnakangas <heikki@enterprisedb.com>
0 siblings, 0 replies; 12+ messages in thread
From: Merlin Moncure @ 2006-10-18 13:20 UTC (permalink / raw)
To: Heikki Linnakangas <heikki@enterprisedb.com>; +Cc: Rohit_Behl <Rohit_Behl@infosys.com>; pgsql-performance
On 10/18/06, Heikki Linnakangas <heikki@enterprisedb.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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Jdbc/postgres performance
@ 2006-10-18 13:31 Merlin Moncure <mmoncure@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 12+ messages in thread
From: Merlin Moncure @ 2006-10-18 13:31 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Bucky Jordan <bjordan@lumeta.com>; Rohit_Behl <Rohit_Behl@infosys.com>; pgsql-performance
On 10/18/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Merlin Moncure" <mmoncure@gmail.com> writes:
> > this is not really a jdbc issue, just a practical problem with
> > prepared statements...
>
> Specifically, that the OP is running a 7.4 backend, which was our
> first venture into prepared parameterized statements. PG 8.1 will
> do better, 8.2 should do better yet.
I haven't looked at 8.2 because I no longer work at my previous
position, but I was significantly affected by this problem through the
8.1 release. The speed advantages of preparing certain types queries
are dramatic and there are some decent use cases for pramaterizing
limit and other input parameters that are difficult to guess.
merlin
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Jdbc/postgres performance
@ 2006-10-22 15:11 Dave Cramer <pg@fastcrypt.com>
parent: Behl, Rohit (Infosys) <Rohit.Behl@uk.bp.com>
0 siblings, 0 replies; 12+ messages in thread
From: Dave Cramer @ 2006-10-22 15:11 UTC (permalink / raw)
To: Behl, Rohit ((Infosys)) <Rohit.Behl@uk.bp.com>; +Cc: pgsql-performance
On 17-Oct-06, at 3:05 PM, Behl, Rohit ((Infosys)) wrote:
> Hi
>
> We are facing performance problems in postgres while executing a
> query. When I execute this query on the server it takes 5-10
> seconds. Also I get good performance while executing this query
> from my code in java with the hard codes values. I face severe
> performance problems when I run it using a prepared statement.
>
> The query is as follows:
>
> Select events.event_id, ctrl.real_name, events.tsds, events.value,
> events.lds, events.correction, ctrl.type, ctrl.freq from
> iso_midw_data_update_events events, iso_midw_control ctrl where
> events.obj_id = ctrl.obj_id and events.event_id > 68971124 order by
> events.event_id limit 2000
>
> The above query executes in 5-10 seconds.
>
> However the below query executes in 8 mins:
>
> 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 ?
> setLong(1, 68971124);
>
> setInt(2, 2000);
>
> The table has close to 5 million rows. The table has the following
> index:
>
> iso_midw_data_update_events_event_id_key
>
> iso_midw_data_update_events_lds_idx
>
> iso_midw_data_update_events_obj_id_idx
>
>
> The table is described as follows:
>
> Columns_name data_type type_name column_size
>
> lds 2 numeric 13
>
> obj_id 2 numeric 6
>
> tsds 2 numeric 13
>
> value 12 varchar 22
>
> correction 2 numeric 1
>
> delta_lds_tsds 2 numeric 13
>
> event_id -5 bigserial 8
>
> Please tell me what I am missing while setting the prepared
> statement. I am using postgres7.4.2. and postgresql-8.1-407.jdbc3.jar.
Try the same query with protocolVersion=2. There are some issues with
prepared statements being slower if the parameters are not the same
type as the column being compared to.
protocol version 2 will issue the query exactly the same as psql
does. Also note that your two queries are not identical. In the
prepared query you cast to bigint ?
Version 8.1.x handles this better I think.
>
> Thanks
>
>
> Regards
>
> Rohit
>
^ permalink raw reply [nested|flat] 12+ messages in thread
end of thread, other threads:[~2006-10-22 15:11 UTC | newest]
Thread overview: 12+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-10-17 19:05 Jdbc/postgres performance Behl, Rohit (Infosys) <Rohit.Behl@uk.bp.com>
2006-10-22 15:11 ` Dave Cramer <pg@fastcrypt.com>
2006-10-17 19:45 Jdbc/postgres performance Rohit_Behl <Rohit_Behl@infosys.com>
2006-10-17 20:28 ` Merlin Moncure <mmoncure@gmail.com>
2006-10-18 00:47 ` Bucky Jordan <bjordan@lumeta.com>
2006-10-18 03:41 ` Merlin Moncure <mmoncure@gmail.com>
2006-10-18 05:19 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-10-18 13:31 ` Merlin Moncure <mmoncure@gmail.com>
2006-10-18 10:10 Re: Jdbc/postgres performance Rohit_Behl <Rohit_Behl@infosys.com>
2006-10-18 11:58 ` Rohit_Behl <Rohit_Behl@infosys.com>
2006-10-18 12:51 ` Heikki Linnakangas <heikki@enterprisedb.com>
2006-10-18 13:20 ` Merlin Moncure <mmoncure@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox