On 20 Jan 2005 at 9:34, Ragnar Hafstaš wrote: > On Wed, 2005-01-19 at 20:37 -0500, 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 > > > > this just confirms that an indexscan is not always better than a > tablescan. by setting random_page_cost to 1, you deceiving the > planner into thinking that the indexscan is almost as effective > as a tablescan. > > > Any suggestions please? > > did you try to increase sort_mem ?
I tried sort_mem = 4096 and then 16384. This did not make a difference. See http://rafb.net/paste/results/AVDqEm55.html Thank you. -- Dan Langille : http://www.langille.org/ BSDCan - The Technical BSD Conference - http://www.bsdcan.org/ ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org