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

Re: statement caching patch from Laszlo Hornyak for review

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: Csaba Nagy <nagy(at)ecircle-ag(dot)com>,List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: statement caching patch from Laszlo Hornyak for review
Date: 2007-08-02 01:02:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc

I posted the proof of concept back in June of last year, and again in  

I searched the archives but was unable to find where you voiced this  
opinion ?

Either way, the patch is written in such a way to be very non- 
invasive to the driver, and the code
will only ever be executed (except for a single if statement) if the  
user enables the feature.

Can you be more specific about why you want this as a separate module ?

On 1-Aug-07, at 4:31 PM, Heikki Linnakangas wrote:

> Csaba Nagy wrote:
>>> In fact, how about kicking our connection pool implementation out  
>>> to an
>>> external module as well? The connection pool and the statement cache
>>> could live together as a pgfoundry project, or as an additional  
>>> jar in
>>> the jdbc project.
>> The postgres ConnectionPool implementation included in the JDBC  
>> project
>> already has some postgres specific bits (e.g. setPreparedThreashold),
>> and I find it is not specific enough, as it is quite hard to set
>> postgres specific settings on the pooled connections otherwise, as  
>> the
>> place where the pool is configured is the natural place where all  
>> other
>> default connection properties should be configured too. So my  
>> opinion is
>> to make the ConnectionPool implementation as specific for postgres  
>> as it
>> is reasonable, allowing to set most of the things you could set on a
>> postgres connection. In particular it would be nice to set the  
>> default
>> properties to pass on when creating a new pooled connection (this is
>> actually not really postgres specific now that I think about it, but
>> prepareThreshold is).
> You could have extra methods to set any driver-specific properties in
> the generic connection pool implementation. With reflection, I  
> think you
> could also create a proxy DataSource class that implements all the  
> same
> driver-specific methods as the underlaying DataSource.
> What do you think of the idea of just moving the current  
> implementation
> to an additional jar?
> -- 
>   Heikki Linnakangas
>   EnterpriseDB
> ---------------------------(end of  
> broadcast)---------------------------
> TIP 6: explain analyze is your friend

In response to


pgsql-jdbc by date

Next:From: Dennis ThrysøeDate: 2007-08-02 07:44:02
Subject: LargeObject API
Previous:From: Heikki LinnakangasDate: 2007-08-01 20:31:50
Subject: Re: statement caching patch from Laszlo Hornyak for review

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