From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Markus Wollny <Markus(dot)Wollny(at)computec(dot)de> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Using FTI-Search (likely a more general runtime-puzzle) |
Date: | 2002-07-24 17:07:45 |
Message-ID: | 20020724095659.G36863-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> This is way too long. I don't know why it doesn't use the indexes I gave
> to it... If someone has got some idea as to what can be done to optimize
> query-planner decisions, I'd be happy to comply. But anyway, I don't
> worry about this too much and just force it to use them, once I know its
> decision for seqential scan is wrong:
Have you vaccum analyzed the fti table?
> Case 3b:
> Retrieving additional article-info:
>
> SET ENABLE_SEQSCAN=OFF;
> EXPLAIN ANALYZE
> SELECT article_id, site_id, article_type, topstory, headline, published
> from article where article_id in (
> select distinct (p.article_id)
> from article p, article_fti f1, article_fti f2, article_fti f3
> where f1.string ='grand' and f2.string ='theft' and f3.string ='auto'
> and p.oid=f1.id and p.oid=f2.id and p.oid=f3.id);
> SET ENABLE_SEQSCAN=ON;
I was going to suggest a subselect in from rather than the IN,
but perhaps you could just use distinct on and get the data from p.
Admittedly this uses a postgresql extension, and assumes that p.article_id
is unique, maybe like:
select distinct on (p.article_id) p.* from
article p, article_fti f1, article_fti f2, article_fti f3
where f1.string ='grand' and f2.string ='theft' and f3.string ='auto'
and p.oid=f1.id and p.oid=f2.id and p.oid=f3.id;
From | Date | Subject | |
---|---|---|---|
Next Message | Phil Davey | 2002-07-24 17:12:40 | Re: RES: [SQL] Queries not using Index |
Previous Message | Nelson Marisco | 2002-07-24 16:56:21 | Inquiry From Form [pgsql] |