Re: Out of memory error on huge resultset

From: snpe <snpe(at)snpe(dot)co(dot)yu>
To: pgsql-jdbc <pgsql-jdbc(at)postgresql(dot)org>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Out of memory error on huge resultset
Date: 2002-10-11 12:27:40
Message-ID: 200210111427.41955.snpe@snpe.co.yu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-jdbc

Barry,
Is it true ?
I create table with one column varchar(500) and enter 1 milion rows with
length 10-20 character.JDBC query 'select * from a' get error 'out of
memory', but psql not.
I insert 8 milion rows and psql work fine yet (slow, but work)

In C library is 'execute query' without fetch - in jdbc execute fetch all rows
and this is problem - I think that executequery must prepare query and fetch
(ResultSet.next or ...) must fetch only fetchSize rows.
I am not sure, but I think that is problem with jdbc, not postgresql
Hackers ?
Does psql fetch all rows and if not how many ?
Can I change fetch size in psql ?
CURSOR , FETCH and MOVE isn't solution.
If I use jdbc in third-party IDE, I can't force this solution

regards

On Thursday 10 October 2002 06:40 pm, Barry Lind wrote:
> Nick,
>
> This has been discussed before on this list many times. But the short
> answer is that that is how the postgres server handles queries. If you
> issue a query the server will return the entire result. (try the same
> query in psql and you will have the same problem). To work around this
> you can use explicit cursors (see the DECLARE CURSOR, FETCH, and MOVE
> sql commands for postgres).
>
> thanks,
> --Barry
>
> Nick Fankhauser wrote:
> > I'm selecting a huge ResultSet from our database- about one million rows,
> > with one of the fields being varchar(500). I get an out of memory error
> > from java.
> >
> > If the whole ResultSet gets stashed in memory, this isn't really
> > surprising, but I'm wondering why this happens (if it does), rather than
> > a subset around the current record being cached and other rows being
> > retrieved as needed.
> >
> > If it turns out that there are good reasons for it to all be in memory,
> > then my question is whether there is a better approach that people
> > typically use in this situation. For now, I'm simply breaking up the
> > select into smaller chunks, but that approach won't be satisfactory in
> > the long run.
> >
> > Thanks
> >
> > -Nick
> >
> > -------------------------------------------------------------------------
> >- Nick Fankhauser nickf(at)ontko(dot)com Phone 1.765.935.4283 Fax
> > 1.765.962.9788 Ray Ontko & Co. Software Consulting Services
> > http://www.ontko.com/
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: Have you checked our extensive FAQ?
> >
> > http://www.postgresql.org/users-lounge/docs/faq.html
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Martijn van Oosterhout 2002-10-11 12:46:14 Re: Pg module and several result objects
Previous Message Timur V. Irmatov 2002-10-11 12:10:28 Pg module and several result objects

Browse pgsql-hackers by date

  From Date Subject
Next Message snpe 2002-10-11 12:37:31 Re: [Fwd: Re: [JDBC] Patch for handling "autocommit=false" in postgresql.conf]
Previous Message Tom Lane 2002-10-11 12:12:50 Re: [HACKERS] number of attributes in page files?

Browse pgsql-jdbc by date

  From Date Subject
Next Message Jeffrey Duffy 2002-10-11 12:35:00 Re: NullPointer error returned from ResultSet.java
Previous Message Dave Cramer 2002-10-11 11:14:08 Re: NullPointer error returned from ResultSet.java