From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Oliver Jowett <oliver(at)opencloud(dot)com> |
Cc: | Robin Houston <robin(dot)houston(at)gmail(dot)com>, PostgreSQL - JDBC <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: Cursor-based results: bafflingly slow |
Date: | 2009-07-03 14:24:35 |
Message-ID: | 749.1246631075@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Oliver Jowett <oliver(at)opencloud(dot)com> writes:
> If you want to stream results promptly, you may be stuck with removing
> that ORDER BY. I'm not sure if there's any way to say to the planner
> "give me a plan with a low startup cost, even if it has a higher total
> cost" which seems to be what you want here.
You need to use a cursor for that. The problem with the fetchsize
mechanism is that it doesn't give the planner any clue that the user
might not intend to fetch the whole result, or might prefer low startup
cost to low total cost anyway.
> I came across some (very old) posts in the archives that suggested that
> DECLARE CURSOR has a fudge where it ranks plan costs assuming that only
> some rows (10%?) will actually be fetched. I'm not sure if that's true
> of the current planner.
Exactly. As of 8.4 you can control the percentage, too.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robin Houston | 2009-07-03 14:38:11 | Re: Cursor-based results: bafflingly slow |
Previous Message | Oliver Jowett | 2009-07-03 14:12:59 | Re: Cursor-based results: bafflingly slow |