Skip site navigation (1) Skip section navigation (2)

Re: Slow fulltext query plan

From: Florent Guillaume <fg(at)nuxeo(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Slow fulltext query plan
Date: 2012-04-16 13:11:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Tom Lane wrote:
> Benoit Delbosc<bdelbosc(at)nuxeo(dot)com>  writes:
>>  On 13/04/2012 00:25, Tom Lane wrote:
>>>  Is there a reason why you're writing the query in such a
>>>  non-straightforward way, rather than just
>>>  FROM hierarchy
>>>  JOIN fulltext ON =
>>>  WHERE (TO_TSQUERY('whatever') @@ nx_to_tsvector(fulltext.fulltext))
>>>  OR (TO_TSQUERY('whatever') @@ nx_to_tsvector(fulltext.fulltext_title));
>>  This query is written by a framework, also I thought that is a common
>>  pattern that can be found in the documentation:
> Well, "common pattern" would be stretching it.  Anyway I've concluded
> that this is in fact a planner bug.  There will be a fix in 9.2, but I'm
> not going to take the risk of back-patching it, so you might want to
> think about changing that framework.

FYI the reason why we have queries that look like what Benoit
describes is that we often use the query alias twice, once for
TO_TSVECTOR and once for TS_RANK_CD, for instance:

  SELECT, TS_RANK_CD(fulltext, query1, 32) as nxscore
  FROM hierarchy
  JOIN fulltext ON =,
  TO_TSQUERY('whatever') query1,
  TO_TSQUERY('whatever') query2
  WHERE (query1 @@ nx_to_tsvector(fulltext.fulltext)) OR (query2 @@
  ORDER BY nxscore DESC;

(as is also described in the doc mentioned btw).


Florent Guillaume, Director of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)   +33 1 40 33 79 87

pgsql-performance by date

Next:From: Tomek WalkuskiDate: 2012-04-16 14:02:13
Subject: SeqScan with full text search
Previous:From: Merlin MoncureDate: 2012-04-16 13:10:18
Subject: Re: scale up (postgresql vs mssql)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group