SEO

Dave Cramer wrote:
> Laszlo Hornyak has finished off the proof of concept patch that I
> submitted a few months ago.
>
> This driver implements prepared statement caching and was used by Sun to
> achieve the excellent results for their benchmark.
>
> Statement caching has proven to provide a 30-40% improvement in the
> benchmark results.

FWIW, I'm still of the opinion that this doesn't belong in the JDBC
driver. Is there anything in there that depends on PostgreSQL? You could
just implement it as a generic wrapper, right?

Don't get me wrong, I know it really can give a big boost in
performance, and it's definitely worth having if your application server
doesn't do statement caching already. I'd just prefer to keep the driver
slim, and implement additional features as external modules.

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.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Heikki,

> 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).

Cheers,
Csaba.




---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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

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


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Dave Cramer wrote:
> 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 ?

It was as a reply to your post last year:

http://archives.postgresql.org/pgsql...6/msg00049.php

Maybe I should've voiced my opinion more strongly back then..

> 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 ?

I'd just like to keep the core JDBC driver slim as a matter of
principle. Given that most application servers already have their own
connection pooling and prepared statement caching implementation, and
the fact that there's other stand-alone implementations out there
(Apache DBCP, for example), most people who need the JDBC driver don't
need another connection pool and statement cache.

As a separate module, the pool and the cache could get a wider audience.
You could use it with different databases and JDBC drivers in addition
to PostgreSQL. And it wouldn't be tied to PostgreSQL driver release
cycle, and vice versa.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On 2-Aug-07, at 3:50 AM, Heikki Linnakangas wrote:

> Dave Cramer wrote:
>> 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 ?
>
> It was as a reply to your post last year:
>
> http://archives.postgresql.org/pgsql...6/msg00049.php
>
> Maybe I should've voiced my opinion more strongly back then..

Yes, that would have been helpful. So can we now turn our attention
to the
technical merits of the patch ?
>
>> 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 ?
>
> I'd just like to keep the core JDBC driver slim as a matter of
> principle. Given that most application servers already have their own
> connection pooling and prepared statement caching implementation, and
> the fact that there's other stand-alone implementations out there
> (Apache DBCP, for example), most people who need the JDBC driver don't
> need another connection pool and statement cache.
>
Well, there is one application server which does not (Sun's).
> As a separate module, the pool and the cache could get a wider
> audience.
> You could use it with different databases and JDBC drivers in addition
> to PostgreSQL. And it wouldn't be tied to PostgreSQL driver release
> cycle, and vice versa.
I'd argue why bother at all since DBCP exists.

Dave
>
> --
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Dave Cramer wrote:
> On 2-Aug-07, at 3:50 AM, Heikki Linnakangas wrote:
>> As a separate module, the pool and the cache could get a wider audience.
>> You could use it with different databases and JDBC drivers in addition
>> to PostgreSQL. And it wouldn't be tied to PostgreSQL driver release
>> cycle, and vice versa.
> I'd argue why bother at all since DBCP exists.

Ok, I'll bite. Why bother at all since DBCP exists?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match