Re: How to interpret this explain analyse?
От | Joost Kraaijeveld |
---|---|
Тема | Re: How to interpret this explain analyse? |
Дата | |
Msg-id | A3D1526C98B7C1409A687E0943EAC41048A15A@obelix.askesis.nl обсуждение исходный текст |
Ответ на | How to interpret this explain analyse? ("Joost Kraaijeveld" <J.Kraaijeveld@Askesis.nl>) |
Список | pgsql-performance |
Hi Tom, Tom Lane schreef: > 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.) I wish I had your mnemory ;-) . The tables contain 1.100.000 records by the way (that is not nearly 10 %, my math is notthat good)) > 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. If the proposal means that the cursor is not limited to ths limit in the query but is limited to the fetch than I supportthe proposal. A bit late I presume. Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 e-mail: J.Kraaijeveld@Askesis.nl web: www.askesis.nl
В списке pgsql-performance по дате отправления: