From: | Sergey Konoplev <gray(dot)ru(at)gmail(dot)com> |
---|---|
To: | Ivan Voras <ivoras(at)freebsd(dot)org> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: tsearch2, large data and indexes |
Date: | 2014-04-24 19:57:50 |
Message-ID: | CAL_0b1sREcX8jtf5O_e4Sd7kNrK3n04n1szPgtBhCdKSTnF46Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, Apr 24, 2014 at 5:34 AM, Ivan Voras <ivoras(at)freebsd(dot)org> wrote:
> On 24 April 2014 13:34, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> wrote:
>
>> As the docs say, the GIN index does not store the weights. As such, there is
>> no need to strip them. A recheck would be necessary if your query needs the
>> weights, precisely because the weights are not included in the index.
>>
>> (In the OP's query, it's the ranking that was causing the detoasting.)
>
> Thanks!
>
> My problem is that I actually need the ranking. My queries can return
> a large number of documents (tens of thousands) but I usually need
> only the first couple of pages of most relevant results (e.g. 50-100
> records). With PostgreSQL and tsearch2, this means that the tens of
> thousands of documents found via the index are then detoasted and
> ranked.
Heikki, what about the "GIN improvements part 3: ordering in index"
patch, was it committed?
Ivan, there is a hope that we could get a more effective FTS solution
that any others I have heard about with this patch.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979
gray(dot)ru(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-04-24 20:29:00 | Re: Poor performance for delete query |
Previous Message | Jonatan Evald Buus | 2014-04-24 19:42:41 | Poor performance for delete query |