Rajesh Kumar Mallah writes:
> co_name_vec is actually the auxiliary tsvector column that is mantained via
> a
> an update trigger. and the index that you suggested is there .
Well, in that case it's just a costing/statistics issue. The planner is
probably estimating there are more tsvector match
The way to make this go faster is to set up the actually recommended
> infrastructure for full text search, namely create an index on
> (co_name_vec)::tsvector (either directly or using an auxiliary tsvector
> column). If you don't want to maintain such an index, fine, but don't
> expect full text
Dear Tom/Kevin/List
thanks for the insight, i will check the suggestion more closely and post
the results.
regds
Rajesh Kumar Mallah.
"Kevin Grittner" writes:
> Rajesh Kumar Mallah wrote:
>> just by removing the order by co_name reduces the query time
>> dramatically from ~ 9 sec to 63 ms. Can anyone please help.
> The reason is that one query allows it to return *any* 25 rows,
> while the other query requires it to find a
Rajesh Kumar Mallah wrote:
> just by removing the order by co_name reduces the query time
> dramatically from ~ 9 sec to 63 ms. Can anyone please help.
The reason is that one query allows it to return *any* 25 rows,
while the other query requires it to find a *specific* set of 25
rows. It h
On Mon, Jun 28, 2010 at 5:09 PM, Yeb Havinga wrote:
> Rajesh Kumar Mallah wrote:
>
>> Dear List,
>>
>> just by removing the order by co_name reduces the query time dramatically
>> from ~ 9 sec to 63 ms. Can anyone please help.
>>
> The 63 ms query result is probably useless since it returns a l
On Monday 28 June 2010 13:39:27 Yeb Havinga wrote:
> It looks like seq_scans are disabled, since the index scan has only a
> filter expression but not an index cond.
Or its using it to get an ordered result...
Andres
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
Rajesh Kumar Mallah wrote:
Dear List,
just by removing the order by co_name reduces the query time dramatically
from ~ 9 sec to 63 ms. Can anyone please help.
The 63 ms query result is probably useless since it returns a limit of
25 rows from an unordered result. It is not surprising that thi
