Fwd: Caching driver on pgFoundry?
| От | László Hornyák |
|---|---|
| Тема | Fwd: Caching driver on pgFoundry? |
| Дата | |
| Msg-id | 809bf8d30709070656q39ffc0fcp8eae7f0ded2d2039@mail.gmail.com обсуждение исходный текст |
| Ответ на | Caching driver on pgFoundry? (Josh Berkus <josh@agliodbs.com>) |
| Ответы |
Re: Fwd: Caching driver on pgFoundry?
|
| Список | pgsql-jdbc |
Sorry, I wanted to send this to the list...
---------- Forwarded message ----------
From: László Hornyák <kocka.public@gmail.com >
Date: 07-Sep-2007 15:55
Subject: Re: [JDBC] Caching driver on pgFoundry?
To: Oliver Jowett <oliver@opencloud.com>
Hi!
--
László Hornyák
--
László Hornyák
---------- Forwarded message ----------
From: László Hornyák <kocka.public@gmail.com >
Date: 07-Sep-2007 15:55
Subject: Re: [JDBC] Caching driver on pgFoundry?
To: Oliver Jowett <oliver@opencloud.com>
Hi!
On 07/09/07, Oliver Jowett <oliver@opencloud.com > wrote:
There are two main reasons I can mention:
- JDBC 4 allows prepared statement pooling (Which is optional, the driver can ignore the programs request to cache the prepared statement, and I believe it enables some kind of early optimization for those who like to do early optimizations. But that is just my opinion, but JDBC 4 specification expects drivers to deal with it. Time will tell, maybe data access layers like hibernate or JPA implementations in the future will use it) see http://java.sun.com/javase/6/docs/api/java/sql/Statement.html#setPoolable%28boolean%29
- Clients that do not use DataSource, but only DriverManager can gain significant speed improvement. Now, you get prepapred statement caching if the wrapper ( e.g. DBCP) gives it, not if you use a pg connection directly.
Yes, any developer can do that, but it would probably save some time for developers if they wouldn't have to.
What is the implementation advantage of making statement pooling part of
the main driver? There are maintenance issues which count *against* it
being part of the driver so you need to provide a good reason to include it.
There are two main reasons I can mention:
- JDBC 4 allows prepared statement pooling (Which is optional, the driver can ignore the programs request to cache the prepared statement, and I believe it enables some kind of early optimization for those who like to do early optimizations. But that is just my opinion, but JDBC 4 specification expects drivers to deal with it. Time will tell, maybe data access layers like hibernate or JPA implementations in the future will use it) see http://java.sun.com/javase/6/docs/api/java/sql/Statement.html#setPoolable%28boolean%29
- Clients that do not use DataSource, but only DriverManager can gain significant speed improvement. Now, you get prepapred statement caching if the wrapper ( e.g. DBCP) gives it, not if you use a pg connection directly.
Packaging issues are IMO fairly irrelevant because if you must give a
single package to your users, you can always take the base driver and a
separate pooling wrapper, package them together, and say "Hey look here
is the statement-pooling postgresql JDBC driver".
Yes, any developer can do that, but it would probably save some time for developers if they wouldn't have to.
-O
---------------------------(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
--
László Hornyák
--
László Hornyák
В списке pgsql-jdbc по дате отправления: