Re: Using FTI-Search (likely a more general runtime-puzzle)

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;

In response to

Browse pgsql-general by date

  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]