"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
