Re: How to interpret this explain analyse?
От | Tom Lane |
---|---|
Тема | Re: How to interpret this explain analyse? |
Дата | |
Msg-id | 13008.1108150825@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: How to interpret this explain analyse? ("Joost Kraaijeveld" <J.Kraaijeveld@Askesis.nl>) |
Ответы |
Re: How to interpret this explain analyse?
|
Список | pgsql-performance |
"Joost Kraaijeveld" <J.Kraaijeveld@Askesis.nl> writes: > I cannot change the query (it is geneated by a tool called Clarion) but it something like (from the psqlodbc_xxx.log): > "... > declare SQL_CUR01 cursor for > SELECT A.ordernummer, B.klantnummer FROM "orders" A LEFT OUTER JOIN "klt_alg" B ON A.Klantnummer=B.Klantnummer ORDER BYA.klantnummer; > fetch 100 in SQL_CUR01; > ..." Well, the planner does put some emphasis on startup time when dealing with a DECLARE CURSOR plan; the problem you face is just that that correction isn't large enough. (From memory, I think it optimizes on the assumption that 10% of the estimated rows will actually be fetched; you evidently want a setting of 1% or even less.) We once talked about setting up a GUC variable to control the percentage of a cursor that is estimated to be fetched: http://archives.postgresql.org/pgsql-hackers/2000-10/msg01108.php It never got done but that seems like the most reasonable solution to me. regards, tom lane
В списке pgsql-performance по дате отправления: