Обсуждение: Full text index not being used, even though it is in the plan

I am trying to use a full text index, but it seems to be reindexing on
every query.

The query plan looks fine, but the queries take extremely long (hours
even).  I think it is reindexing because it is notifying me that
certain long "words" won't be indexed as you can see below, which is
what it does when I create the index.



=> explain select id from source_listings where
plainto_tsquery('view') @@ to_tsvector('english', full_listing);
                                                QUERY PLAN
--------------------------------------------------------------------------------------------------------
  Bitmap Heap Scan on source_listings  (cost=1454.88..7445.47
rows=1595 width=4)
    Recheck Cond: (plainto_tsquery('view'::text) @@
to_tsvector('english'::regconfig, full_listing))
    ->  Bitmap Index Scan on kw2_index  (cost=0.00..1454.48 rows=1595
width=0)
          Index Cond: (plainto_tsquery('view'::text) @@
to_tsvector('english'::regconfig, full_listing))

=> explain analyze select id from source_listings where
plainto_tsquery('view') @@ to_tsvector('english', full_listing);
NOTICE:  word is too long to be indexed
DETAIL:  Words longer than 2047 characters are ignored.
NOTICE:  word is too long to be indexed
DETAIL:  Words longer than 2047 characters are ignored.
... it just keeps building a new index until I kill it
Cancel request sent

Alex Neth <alex@liivid.com> writes:

> I am trying to use a full text index, but it seems to be reindexing on  every
> query.
>
> The query plan looks fine, but the queries take extremely long (hours  even).
> I think it is reindexing because it is notifying me that  certain long "words"
> won't be indexed as you can see below, which is  what it does when I create the
> index.

I don't think it's reindexing, it's just calling to_tsvector() which it has to
do when it rechecks rows that the index says might match.

Is it possible that nearly all the full_listing values contain "view"? How
does it perform with much more selective searches?

If your full_listing values are quite large then recalculating the tsvector
might be a lot more expensive than doing a full table scan and LIKE match for
cases when nearly the whole table is going to be scanned anyways.

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's On-Demand Production Tuning