Re: tsearch2, large data and indexes

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?

http://www.postgresql.org/message-id/flat/CAPpHfduWvqv5b0XZ1DZuqAW29erDCULZp2wotfJzDBs7BHpKXw(at)mail(dot)gmail(dot)com

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

In response to

Responses

Browse pgsql-performance by date

  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