Re: SELECT very slow

Поиск
Список
Период
Сортировка
От Thomas Kellerer
Тема Re: SELECT very slow
Дата
Msg-id d8s30h$r12$1@sea.gmane.org
обсуждение исходный текст
Ответ на Re: SELECT very slow  (Scott Marlowe <smarlowe@g2switchworks.com>)
Ответы Re: SELECT very slow
Список 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



В списке pgsql-sql по дате отправления:

Предыдущее
От: "Jim Buttafuoco"
Дата:
Сообщение: Re: funny update, say update 1, updated 1 added 2nd.
Следующее
От: Andrew Sullivan
Дата:
Сообщение: Re: cursor "" does not exist