From: | Nicolas Grilly <nicolas(at)gardentechno(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Cc: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
Subject: | Re: ts_rank seems very slow (140 ranked documents / second on my machine) |
Date: | 2012-03-07 18:51:55 |
Message-ID: | CAG3yVS4axMv0ELL8RXhmhnCsL422yXOR7W=hqDO7ZokoE3E2Ng@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Reopening a six months old discussion... Is there any plans to improve
ts_rank performance by making it able to use GIN/GIST indices?
From re-reading Oleg answers, I understand FTS indices do not contain
enough information for ts_rank. Because of that, ts_rank has to read the
ts_vector, which is stored in TOAST table, which triggers a random read for
each ranked document.
Cheers,
Nicolas Grilly
On Wed, Jul 13, 2011 at 18:55, Nicolas Grilly <nicolas(at)gardentechno(dot)com>wrote:
> The first query ran in 347 seconds; the second one in 374 seconds.
> Conclusion: There is no significant overhead in the ts_rank function
> itself. It's slow because ts_rank has to read in random order 40 000
> ts_vector stored in TOAST table. The slow execution time looks like
> a direct consequence of storing ts_vector in TOAST table...
>
> > :( The only solution I see is to store enough information for ranking
> in index.
>
> Is it the expected behavior? How can I improve that?
>
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gould | 2012-03-07 18:58:24 | Re: Automated Backup Script Help (Linux) |
Previous Message | mgould | 2012-03-07 18:51:33 | Converting stored procedures from SQL Anywhere to PostGres. |