From: Thomas Kellerer <spam_eater@gmx.net>
To: pgsql-sql@postgresql.org
Subject: Re: SELECT very slow
Date: Thu, 16 Jun 2005 16:45:35 +0200
Message-ID: <d8s30h$r12$1@sea.gmane.org> (raw)
In-Reply-To: <1118930439.3382.91.camel@state.g2switchworks.com>
References: <d87ood$8vq$1@sea.gmane.org>
<d8pqbi$a5q$1@sea.gmane.org>
<op.ssc0t7wrth1vuj@localhost>
<op.ssfgo6xath1vuj@localhost>
<d8q8iq$pfg$1@sea.gmane.org>
<1118930439.3382.91.camel@state.g2switchworks.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: spam_eater@gmx.net
Subject: Re: SELECT very slow
In-Reply-To: <d8s30h$r12$1@sea.gmane.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox