On Thu, 20 Jan 2005, Dan Langille wrote: > On 20 Jan 2005 at 6:14, Stephan Szabo wrote: > > > On Wed, 19 Jan 2005, Dan Langille wrote: > > > > > Hi folks, > > > > > > Running on 7.4.2, recently vacuum analysed the three tables in > > > question. > > > > > > The query plan in question changes dramatically when a WHERE clause > > > changes from ports.broken to ports.deprecated. I don't see why. > > > Well, I do see why: a sequential scan of a 130,000 rows. The query > > > goes from 13ms to 1100ms because the of this. The full plans are at > > > http://rafb.net/paste/results/v8ccvQ54.html > > > > > > I have tried some tuning by: > > > > > > set effective_cache_size to 4000, was 1000 > > > set random_page_cost to 1, was 4 > > > > > > The resulting plan changes, but no speed improvment, are at > > > http://rafb.net/paste/results/rV8khJ18.html > > > > > > Any suggestions please? > > > > As a question, what does it do if enable_hashjoin is false? I'm wondering > > if it'll pick a nested loop for that step for the element/ports join and > > what it estimates the cost to be. > > With enable_hashjoin = false, no speed improvement. Execution plan > at http://rafb.net/paste/results/qtSFVM72.html
Honestly I expected it to be slower (which it was), but I figured it's worth seeing what alternate plans it'll generate (specifically to see how it cost a nested loop on that join to compare to the fast plan). Unfortunately, it generated a merge join, so I think it might require both enable_hashjoin=false and enable_mergejoin=false to get it which is likely to be even slower in practice but still may be useful to see. ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match