From: | Jack Orenstein <jack(dot)orenstein(at)hds(dot)com> |
---|---|
To: | Tomasz Ostrowski <tometzky(at)batory(dot)org(dot)pl> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Autocommit, isolation level, and vacuum behavior |
Date: | 2008-09-12 13:51:51 |
Message-ID: | 48CA73F7.10405@hds.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tomasz Ostrowski wrote:
> On 2008-09-11 18:03, Jack Orenstein wrote:
>
>>> When you do:
>>> result = query("select something from sometable")
>>> then all rows of a result will be cached by a client program.
>> I am very sure this is not happening. Maybe some rows are being
>> cached (specifying fetch size), but certainly not all of them. It
>> used to, with older drivers, (7.4?) but I've been using 8.1 drivers
>> (at least) for a long time. Maybe some result set options you're
>> using cause such memory usage?
>
> Wanna bet?
>
> http://jdbc.postgresql.org/documentation/83/query.html#query-with-cursor
> | There a number of restrictions which will make the driver silently
> | fall back to fetching the whole ResultSet at once. (...) The
> | Connection must not be in autocommit mode. The backend closes cursors
> | at the end of transactions, so in autocommit mode the backend will
> | have closed the cursor before anything can be fetched from it.
>
> So, when you turn on autocommit then it is caching it all. Fetch size is
> ignored.
Well that explains what I've been seeing (autocommit on scan producing behavior
that looks like SERIALIZABLE). Not the behavior I would prefer, but I understand
it now.
Jack
From | Date | Subject | |
---|---|---|---|
Next Message | Jack Orenstein | 2008-09-12 13:52:29 | Re: Autocommit, isolation level, and vacuum behavior |
Previous Message | Andrus | 2008-09-12 13:27:27 | Converting string to IN query |