Re: Question about DBCP prepared statement pooling with - Mailing list pgsql-jdbc

From Mark Lewis
Subject Re: Question about DBCP prepared statement pooling with
Date
Msg-id 1141252523.12885.21.camel@archimedes
Whole thread Raw
In response to Question about DBCP prepared statement pooling with postgres  ("George Woodring" <george.woodring@iglass.net>)
List pgsql-jdbc
If the heavily updated database is so heavily updated that statistics
are wildly volatile, such as one table having 5 million rows one minute
and a dozen the next minute, then back to 5 million, then you probably
don't want to use server-side prepared plans.

More likely however is that even if your database is heavily updated,
the average statistical properties of the tables don't change much, in
which case using server-side prepared plans is usually a good thing.

If you've decided that the statistical distribution of your data doesn't
change too much and you'd like to use server-side prepared plans, then
look at the docs here for how to make JDBC PreparedStatement == Server
prepared plan: http://jdbc.postgresql.org/documentation/81/server-
prepare.html

-- Mark Lewis

On Wed, 2006-03-01 at 17:00 -0500, George Woodring wrote:
> We are looking at implementing prepared statement pooling and I have a
> question if it provides any gains with a heavily updated database.  I am
> worried that the query plans will become stale an inefficient.
>
> A coworker mentioned "jdbc prepared statement" != "psql or perl prepared
> statement" and it is recommended for web environments (which we are).
>
> Any suggestions would be appreciated.
>
> Thanks,
> Woody
>
> ----------------------------------------
> iGLASS Networks
> 211-A S. Salem St
> Apex NC 27502
> (919) 387-3550 x813
> www.iglass.net
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

pgsql-jdbc by date:

Previous
From: "George Woodring"
Date:
Subject: Question about DBCP prepared statement pooling with postgres
Next
From: Kris Jurka
Date:
Subject: Re: Bad Value for Data Type Timestamp