Re: BUG #16235: ts_rank ignores match and only considers lower weighted vector

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: dominik(dot)giger(at)gmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16235: ts_rank ignores match and only considers lower weighted vector
Date: 2020-01-27 22:34:58
Message-ID: 23961.1580164498@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> The following query shows the problem:

> select ts_rank(doc1, query) as rank_wrong, ts_rank(doc2, query) as
> rank_correct
> from (select setweight(to_tsvector('simple', 'foo something'), 'A') ||
> setweight(to_tsvector('simple', 'foobar'), 'C') as doc1,
> setweight(to_tsvector('simple', 'foo something'), 'A') as
> doc2,
> to_tsquery('simple', 'foo:* & something') as
> query) as subquery;

> ts_rank on doc1 is only half of the rank of doc2. ts_rank seems to only
> consider the 'foobar' term with lower weight when calculating the rank. The
> foo:1A is only considered in doc2.

No, that's not correct. What it actually is doing is taking some sort of
average of the weights of the occurrences, as you can see if you play
around with a few more examples besides these two. That could be better
documented, perhaps, but I don't think it's obviously broken.

I can see that there might be a use for taking the max or even the sum
of the weights rather than an average --- in many situations it wouldn't
be desirable to rank doc1 of your example lower than doc2. But really
that'd be a different ranking algorithm, not a bug fix for this one.

The manual claims you can write your own ranking algorithm ... but
AFAICS you'd have to code it in C, because we aren't exposing anything
at SQL level that would let you get at the raw match data :-(.
So there's room for improvement there.

Also, you might try using ts_rank_cd() instead, as that uses a different
algorithm for combining the weights. At least on this example, doc1
gets a higher score than doc2.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2020-01-27 23:05:45 Re: BUG #16236: Invalid escape encoding
Previous Message PG Bug reporting form 2020-01-27 22:21:55 BUG #16236: Invalid escape encoding