Re: Optimizing Query

From: Mathijs Brands <mathijs(at)ilse(dot)nl>
To: Justin Long <justinlong(at)strategicnetwork(dot)org>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: Optimizing Query
Date: 2001-03-05 23:08:50
Message-ID: 20010306000850.I22983@ilse.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

On Mon, Mar 05, 2001 at 04:59:47PM -0500, Justin Long allegedly wrote:
> Ok, now I have another question... it doesn't seem to be accessing the index.
>
> explain select k.kbid,k.title from knowledge k , kbwords w0 , kbwords w1
> WHERE ((k.kbid=w0.kbid and w0.wordid=42743) AND (k.kbid=w1.kbid and
> w1.wordid=85369))
>
> NOTICE: QUERY PLAN:
>
> Merge Join (cost=32339.30..35496.97 rows=19262538 width=24)
> -> Merge Join (cost=16530.24..16668.77 rows=233274 width=20)
> -> Sort (cost=15809.06..15809.06 rows=8257 width=4)
> -> Seq Scan on kbwords w1 (cost=0.00..15271.85 rows=8257
> width=4)
> -> Sort (cost=721.18..721.18 rows=2825 width=16)
> -> Seq Scan on knowledge k (cost=0.00..559.25 rows=2825
> width=16)
> -> Sort (cost=15809.06..15809.06 rows=8257 width=4)
> -> Seq Scan on kbwords w0 (cost=0.00..15271.85 rows=8257 width=4)
>
> Note the sequential scans... there is a wordindex where w0.wordid=42743...
> why isn't it doing an indexscan? wouldn't that be more efficient?
>
> Justin

Did you run the 'vacuum analyze' command on the tables concerned (or even
better, the whole database)? Without the data this analysis provides psql
cannot come up with a good execution plan and falls back to full table
scans. Do a 'vacuum analyze' one a week to keep performance levels up.

Cheers,

Mathijs
--
It's not that perl programmers are idiots, it's that the language
rewards idiotic behavior in a way that no other language or tool has
ever done.
Erik Naggum

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Tom Lane 2001-03-05 23:23:45 Re: Extending PostgreSQL Using C
Previous Message Mathijs Brands 2001-03-05 23:06:25 Re: Two way encryption in PG???