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 по дате отправления: