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 protoco
On Wed, 21 Apr 2010, Robert Haas wrote:
On Tue, Apr 20, 2010 at 5:05 PM, Kris Jurka 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 other optimizations
On Wed, Apr 21, 2010 at 11:30 AM, Tom Lane wrote:
> >> On Tue, Apr 20, 2010 at 5:05 PM, Kris Jurka 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 o
>> On Tue, Apr 20, 2010 at 5:05 PM, Kris Jurka 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 values subs
On Wed, Apr 21, 2010 at 10:41 AM, Robert Haas wrote:
> On Tue, Apr 20, 2010 at 5:05 PM, Kris Jurka 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 thr
On Tue, Apr 20, 2010 at 5:05 PM, Kris Jurka 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 exact param
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 PreparedStatemen
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
Dave Crooke 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 user friend
On Tue, Apr 20, 2010 at 3:29 PM, Dave Crooke 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
> compliant.
>
Dave,
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 minority
Dave Crooke 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 ResultSet as the
re
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 h
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, s
Dave Crooke wrote:
> I'd consider the fact that ResultSet.close() does not release the
> implicit cursor to be something of a bug
What's your reasoning on that? The definitions of cursors in the
spec, if memory serves, allow a cursor to be closed and re-opened;
why would this be treated diffe
15 matches
Mail list logo
