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
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
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