On Tue, Apr 20, 2010 at 5:05 PM, Kris Jurka bo...@ejurka.com wrote:
The reason this is not done is that the mechanism used for fetching a piece
of the results at a time can change the query plan used if using a
PreparedStatement. There are three ways to plan a PreparedStatement:
a) Using the
On Wed, Apr 21, 2010 at 10:41 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Apr 20, 2010 at 5:05 PM, Kris Jurka bo...@ejurka.com wrote:
The reason this is not done is that the mechanism used for fetching a
piece
of the results at a time can change the query plan used if using a
On Tue, Apr 20, 2010 at 5:05 PM, Kris Jurka bo...@ejurka.com wrote:
... There are three ways to plan a PreparedStatement:
FWIW, I think there is some consensus to experiment (in the 9.1 cycle)
with making the server automatically try replanning of parameterized
queries with the actual parameter
On Wed, Apr 21, 2010 at 11:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
On Tue, Apr 20, 2010 at 5:05 PM, Kris Jurka bo...@ejurka.com wrote:
... There are three ways to plan a PreparedStatement:
FWIW, I think there is some consensus to experiment (in the 9.1 cycle)
with making the server
On Wed, 21 Apr 2010, Robert Haas wrote:
On Tue, Apr 20, 2010 at 5:05 PM, Kris Jurka bo...@ejurka.com wrote:
b) Using the parameter values for statistics, but not making any stronger
guarantees about them. So the parameters will be used for evaluating the
selectivity, but not to perform
On Wed, 21 Apr 2010, Nikolas Everett wrote:
More to the point is there some option that can shift you into method a?
I'm thinking of warehousing type applications where you want to re-plan
a good portion of your queries.
This can be done by connecting to the database using the V2
AFAICT from the Java end, ResultSet.close() is supposed to be final. There
is no way I know of in JDBC to get a handle back to the cursor on the server
side once you have made this call - in fact, its sole purpose is to inform
the server in a timely fashion that this cursor is no longer required,
On Mon, 19 Apr 2010, Dave Crooke wrote:
Statement.close() appears to get the job done (in my envrionment, PG's
driver never sees a Connection.close() because of DBCP).
I'd consider the fact that ResultSet.close() does not release the implicit
cursor to be something of a bug, but it may well
Dave Crooke dcro...@gmail.com wrote:
AFAICT from the Java end, ResultSet.close() is supposed to be
final.
For that ResultSet. That doesn't mean a ResultSet defines a cursor.
Such methods as setCursorName, setFetchSize, and setFetchDirection
are associated with a Statement. Think of the
I don't want to get into a big debate about standards, but I will clarify a
couple of things inline below.
My key point is that the PG JDBC driver resets people's expecations who have
used JDBC with other databases, and that is going to reflect negatively on
Postgres if Postgres is in the
On Tue, Apr 20, 2010 at 3:29 PM, Dave Crooke dcro...@gmail.com wrote:
I wouldn't hold MySQL up to be a particularly good implmentation of
anything, other than speed (MyISAM) and usability (the CLI) I find
Oracle's JDBC implmentation to be both user friendly and (largely) standards
Dave Crooke dcro...@gmail.com wrote:
a. the fact that Statement.executeQuery(select * from
huge_table) works out of the box with every one of those
databases, but results in java.langOutOfMemory with PG without
special setup. Again, this is to the letter of the standard, it's
just not very
I digest this down to this is the best that can be achieved on a connection
that's single threaded
I think the big difference with Oracle is this:
i. in Oracle, a SELECT does not have to be a transaction, in the sense that
PG's SELECT does ... but in Oracle, a SELECT can fail mid-stream if you
On Tue, 20 Apr 2010, Dave Crooke wrote:
a. Make setFetchSize(1) the default
The reason this is not done is that the mechanism used for fetching a
piece of the results at a time can change the query plan used if using a
PreparedStatement. There are three ways to plan a
14 matches
Mail list logo
