Re: Out of memory error on huge resultset
От | Dave Cramer |
---|---|
Тема | Re: Out of memory error on huge resultset |
Дата | |
Msg-id | 1034346630.1796.74.camel@inspiron.cramers обсуждение исходный текст |
Ответ на | Re: Out of memory error on huge resultset (Aaron Mulder <ammulder@alumni.princeton.edu>) |
Ответы |
Re: Out of memory error on huge resultset
|
Список | pgsql-jdbc |
No disadvantage, in fact that is what we would like to do. setFetchSize(size) turns on cursor support, otherwise fetch normally Dave On Fri, 2002-10-11 at 10:30, Aaron Mulder wrote: > What would be the disadvantage of making the JDBC driver use a > cursor under the covers (always)? Is it significantly slower or more > resource-intensive than fetching all the data at once? Certainly it seems > like it would save memory in some cases. > > Aaron > > On 10 Oct 2002, Dave Cramer wrote: > > Nick, > > > > Use a cursor, the current driver doesn't support caching, the backend > > gives you everything you ask for, you can't just say you want a limited > > set. > > > > So if you use cursors you can fetch a subset > > > > Dave > > On Thu, 2002-10-10 at 11:24, 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@ontko.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 4: Don't 'kill -9' the postmaster > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > >
В списке pgsql-jdbc по дате отправления: