Re: SELECT very slow

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

In response to

Responses

Browse pgsql-sql by date

  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.