From: | Dave Cramer <pg(at)fastcrypt(dot)com> |
---|---|
To: | fschmidt <fschmidt(at)gmail(dot)com> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: setFetchSize |
Date: | 2011-10-26 19:18:09 |
Message-ID: | CADK3HHLrGmJkdcCcYoHV9BpMSg+jTXJ3X4LtzhvhRzvaedAWtQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On Wed, Oct 26, 2011 at 11:48 AM, fschmidt <fschmidt(at)gmail(dot)com> wrote:
>
> Dave Cramer-8 wrote:
>>
>> There is little hope that you will get what you want. I'm not even
>> sure I think it's a good idea as cursor with hold consumes resources
>> on the server which multiplied by an unknown number of connections
>> might end up being significant.
>>
> And how is it any better to force users to open a new connection to use
> setFetchSize? This would use just as much resources if not more, right? It
> is just much more inconvenient for programmers, especially in applications
> like mine that are designed to use one connection per thread.
My understanding is this: Postgresql is an MVCC database and can
easily provide you with a snapshot of a resultset inside a
transaction. Outside a transaction my bet is that the data has to be
copied to a temporary location somewhere, so if this is done over N
connections the resources required could be substantial.
>
> If there is little hope of getting what I want with Postgres, then I will
> eventually have to look for an alternative database.
Well every database I know of has it's idiosyncrasies, an as I said
the JDBC spec makes no guarantees of what setFetchSize should do if
anything.
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
From | Date | Subject | |
---|---|---|---|
Next Message | fschmidt | 2011-10-26 20:22:07 | Re: setFetchSize |
Previous Message | fschmidt | 2011-10-26 15:48:42 | Re: setFetchSize |