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: 96F22561-D20B-4BD2-8C5C-1E83953DAA4C@fastcrypt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Heikki,

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

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 ?

Dave
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 http://www.enterprisedb.com
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 6: explain analyze is your friend

In response to

Responses

Browse pgsql-jdbc by date

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