From: | Thomas Kellerer <spam_eater(at)gmx(dot)net> |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: SELECT very slow |
Date: | 2005-06-16 14:45:35 |
Message-ID: | d8s30h$r12$1@sea.gmane.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On 16.06.2005 16:00 Scott Marlowe wrote:
> There's got to be more happening than what this is showing us. A
> select, and looping through it, should involve no writes, and therefore
> no real performance difference from autocommit versus not. Is there
> some underlying trigger on the view or something like that? Some kind
> of auditing function?
That's exactly the code that produced the mentioned timings. This is - according
to the JDBC driver's documentation - the expected behaviour. The driver can be
set to use cursor based fetching but *only* if autocommit is false.
If autocommit is on (or fetch size is zero) then the driver will build the whole
result set before returning to the caller.
http://jdbc.postgresql.org/documentation/80/query.html#query-with-cursor
Thomas
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2005-06-16 14:54:34 | Re: cursor "<unnamed portal 1>" does not exist |
Previous Message | Jim Buttafuoco | 2005-06-16 14:05:13 | Re: funny update, say update 1, updated 1 added 2nd. |