Janning writes:
> But I remember a post of tom lane who said that prepared statements get
> replaned since 8.4 if underlying statistics change.
Since 8.3, IIRC. 8.4 extended the mechanism to apply in some more
cases, but an ANALYZE should cause a replan in 8.3.
regards,
On Wed, Jun 02, 2010 at 10:10:24AM +0200, Janning wrote:
> But I remember a post of tom lane who said that prepared statements get
> replaned since 8.4 if underlying statistics change. But I really can't find
> it.
> Maybe I do not remember correctly.
I saw a similar post yesterday, and think I
> > > > I remember postgresql 8.4 is replanning prepared statements when
> > > > statistics change occur, but I didn't find it in the release notes.
> > > > It is just saying "Invalidate cached plans when referenced schemas,
> > > > functions, operators, or operator classes are modified". Does PG
>
On Fri, May 28, 2010 at 10:09:22PM +0200, Janning wrote:
> On Thursday 27 May 2010 16:56:28 you wrote:
> > > Additionally c3p0 can cache java instances of
> > > "java.sql.PreparedStatement" which means it is caching the java object.
> > > So when using
> > > c3p0.maxStatementsPerConnection = 100
On Thursday 27 May 2010 16:56:28 you wrote:
> > Additionally c3p0 can cache java instances of
> > "java.sql.PreparedStatement" which means it is caching the java object.
> > So when using
> > c3p0.maxStatementsPerConnection = 100 it caches at most 100 different
> > objects. It saves time on crea
On Tue, May 25, 2010 at 05:28:10PM +0200, Janning wrote:
> Our hibernate stack uses prepared statements. Postgresql is caching the
> execution plan. Next time the same statement is used, postgresql reuses the
> execution plan. This saves time planning statements inside DB.
It only uses the cache
