Skip site navigation (1) Skip section navigation (2)

Re: Queries with large ResultSets

From: Andrea Aime <andrea(dot)aime(at)aliceposta(dot)it>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: Jack Orenstein <jao(at)geophile(dot)com>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Queries with large ResultSets
Date: 2004-05-20 18:22:37
Message-ID: 200405202022.37646.andrea.aime@aliceposta.it (view raw or flat)
Thread:
Lists: pgsql-jdbc
Alle 18:01, giovedì 20 maggio 2004, Kris Jurka ha scritto:
> On Wed, 19 May 2004, Jack Orenstein wrote:
> > If I'm reading the source code correctly, the PostgreSQL 7.3.4 JDBC
> > driver creates a ResultSet by evaluating the entire query, and putting
> > all the rows into a Vector. ResultSet.next() iterates over the
> > Vector. Is that in fact what is happening?
>
> Yes, in the 7.3 driver.  The 7.4 driver (which works quite well against a
> 7.3 database) will use a cursor based fetch to retrieve a chunk of rows at
> a time.  There are a number of restrictions required to be able to use
> this method (It only works with autocommit off and FORWARD_ONLY result
> sets).  To enable this use Statement.setFetchSize to indicate how many
> rows at a time you want retrieved.  Also there is a patch to the 7.5
> driver to be able to retrieve subsets of the resultset for the scrollable
> variety and hopefully I should get that in soon.

Ugh... those limitation are really frightening, this means we cannot fetch
big quantities of data outside of a transaction... this is a problem with 
application servers like GeoServer that keep a connection pool and 
need to fetch big quantities of data also outside a transaction... any hope
to see this fixed soon? Is it a driver problem or a server limitation?

Best regards
Andrea Aime

In response to

Responses

pgsql-jdbc by date

Next:From: Tom LaneDate: 2004-05-20 18:44:24
Subject: Re: Queries with large ResultSets
Previous:From: Kris JurkaDate: 2004-05-20 16:01:09
Subject: Re: Queries with large ResultSets

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group