Re: Optimizing Query

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Justin Long <justinlong(at)strategicnetwork(dot)org>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: Optimizing Query
Date: 2001-03-05 21:07:57
Message-ID: 200103052107.QAA02196@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Have you tried VACUUM ANALYZE and CLUSTER?

> Any suggestions welcome!
>
> Here is my query:
>
> select k.*, c.category from knowledge k, kb_categories c , kbwords w0 ,
> kbwords w1 WHERE k.catid=c.catid AND ((k.kbid=w0.kbid and w0.wordid=42743)
> AND (k.kbid=w1.kbid and w1.wordid=85369)) ORDER BY k.kbid DESC LIMIT 25;
>
> Now for the details
> knowledge k = 3,150 records
> kbwords = 2-field database (kbid, wordid), 825,748 records
>
> Each word in the knowledge base is stored in a database called wordindex,
> which has 50,000 records or so. The system first explodes the query string
> and pulls the word #s from this database, which is where we get 42743 and
> 85369 above, "ASIA" and "CHILDREN" respectively.) The idea is then to pull
> all the articles in the knowledge base which contain both of these words.
>
> Here is the EXPLAIN for the query:
>
> NOTICE: QUERY PLAN:
>
> Nested Loop (cost=0.00..527690060.67 rows=2878549 width=308)
> -> Nested Loop (cost=0.00..9472443.40 rows=52582 width=304)
> -> Nested Loop (cost=0.00..6278.63 rows=960 width=300)
> -> Index Scan Backward using knowledge_kbid_key on
> knowledge k (cost=0.00..1292.51 rows=2825 width=284)
> -> Seq Scan on kb_categories c (cost=0.00..1.34 rows=34
> width=16)
> -> Seq Scan on kbwords w0 (cost=0.00..9787.02 rows=5474 width=4)
> -> Seq Scan on kbwords w1 (cost=0.00..9787.02 rows=5474 width=4)
>
> This takes quite a while to return results... prohibitively long. There are
> indexes on k.catid, c.catid, k.kbid, w0.kbid, w0.wordid. Any suggestions
> for further optimization would be very welcome. We get about 3,000 searches
> on our database daily...
>
> Blessings,
> Justin Long
>
>
>
> ____________________________________________________________________
> Justin Long Network for Strategic Missions
> justinlong(at)strategicnetwork(dot)org 1732 South Park Court
> http://www.strategicnetwork.org Chesapeake, VA 23320, USA
> Reality Check e-zine: reality-check-subscribe(at)yahoogroups(dot)com
> ____________________________________________________________________
> Law: Never retreat. Never surrender. Never cut a deal with a dragon.
> Corollary: No armor? Unclean life? Then do not mess in the affairs
> of dragons, for you are crunchy and taste good with ketchup.
>
>
> ____________________________________________________________________
> Justin Long Network for Strategic Missions
> justinlong(at)strategicnetwork(dot)org 1732 South Park Court
> http://www.strategicnetwork.org Chesapeake, VA 23320, USA
> Reality Check e-zine: reality-check-subscribe(at)yahoogroups(dot)com
> ____________________________________________________________________
> Law: Never retreat. Never surrender. Never cut a deal with a dragon.
> Corollary: No armor? Unclean life? Then do not mess in the affairs
> of dragons, for you are crunchy and taste good with ketchup.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Stephan Szabo 2001-03-05 21:20:56 Re: random
Previous Message Bruce Momjian 2001-03-05 21:05:31 Re: [SQL] PL/SQL-to-PL/PgSQL-HOWTO beta Available