From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Joost Kraaijeveld" <J(dot)Kraaijeveld(at)Askesis(dot)nl> |
Cc: | "Richard Huxton" <dev(at)archonet(dot)com>, "Pgsql-Performance (E-mail)" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: How to interpret this explain analyse? |
Date: | 2005-02-11 19:40:25 |
Message-ID: | 13008.1108150825@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
"Joost Kraaijeveld" <J(dot)Kraaijeveld(at)Askesis(dot)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 BY A.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
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2005-02-11 20:41:58 | Re: Benchmark |
Previous Message | Joost Kraaijeveld | 2005-02-11 19:25:11 | Re: How to interpret this explain analyse? |