Does the planner also take into account that the Hash Join will need a huge temporary space which will exist for the whole length of the cursor existence (which may be quite long if he intends to fetch everything), whereas the Merge Join should need very little space as it is sending the rows as it fetches them using the Indexes ?

On Mon, 07 Feb 2005 12:03:56 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:

"Joost Kraaijeveld" <[EMAIL PROTECTED]> writes:
Two queries: one with "set enable_seqscan = on" , the other with "set enable_seqscan = off". The first query lasts 59403 ms, the second query 31 ms ( the desc order variant has the same large difference: 122494 ms vs. 1297 ms). (for the query plans see below).

The reason for the difference is that the mergejoin plan has a much lower startup cost than the hash plan, and since you're only fetching 100 rows the startup cost is dominant. IIRC the planner does make some allowance for this effect when preparing a DECLARE CURSOR plan (ie, it puts some weight on startup cost rather than considering only total cost) ... but it's not so optimistic as to assume that you only want 100 out of an estimated 1 million+ result rows.

The best solution is probably to put a LIMIT into the DECLARE CURSOR,
so that the planner can see how much you intend to fetch.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Reply via email to