Re: [PERFORM] An unwanted seqscan

2007-02-14 Thread Brian Herlihy
From: Tom Lane <[EMAIL PROTECTED]> To: Brian Herlihy <[EMAIL PROTECTED]> Cc: Postgresql Performance Sent: Wednesday, 14 February, 2007 4:53:54 PM Subject: Re: [PERFORM] An unwanted seqscan Brian Herlihy <[EMAIL PROTECTED]> writes: > I am having trouble understanding wh

Re: [PERFORM] An unwanted seqscan

2007-02-14 Thread Tom Lane
Brian Herlihy <[EMAIL PROTECTED]> writes: > I am having trouble understanding why a seqscan is chosen for this query. As far as anyone can see from this output, the planner's decisions are correct: it prefers the plans with the smaller estimated cost. If you want us to take an interest, provide s

[PERFORM] An unwanted seqscan

2007-02-14 Thread Brian Herlihy
Hi, I am having trouble understanding why a seqscan is chosen for this query. In practice the seqscan is very expensive, whereas the nested loop is usually quite fast, even with several hundred rows returned from meta_keywords_url. The server is running version 8.1.3, and both tables were analy