Re: [HACKERS] Remove 1MB size limit in tsvector - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] Remove 1MB size limit in tsvector
Date
Msg-id CAB7nPqRW1d3rcWd5syatSPWbMedhD8FDnxo5-JrmoQdC5wFVQQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Remove 1MB size limit in tsvector  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
On Mon, Sep 11, 2017 at 9:51 PM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> On 09/11/2017 01:54 PM, Robert Haas wrote:
>> On Mon, Sep 11, 2017 at 5:33 AM, Ildus Kurbangaliev
>> <i.kurbangaliev@postgrespro.ru> wrote:
>>> Moreover, RUM index
>>> stores positions + lexemes, so it doesn't need tsvectors for ranked
>>> search. As a result, tsvector becomes a storage for
>>> building indexes (indexable type), not something that should be used at
>>> runtime. And the change of the format doesn't affect index creation
>>> time.
>>
>> RUM indexes, though, are not in core.
>>
>
> Yeah, but I think Ildus has a point that this should not really matter
> on indexed tsvectors. So the question is how realistic that benchmark
> actually is. How likely are we to do queries on fts directly, not
> through a GIN/GiST index? Particularly in performance-sensitive cases?

So many questions unanswered... I am marking the patch as returned
with feedback as the thread has stalled for two months now.
-- 
Michael


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] [PATCH] Pattern based listeners for asynchronousmessaging (LISTEN/NOTIFY)
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] INSERT ON CONFLICT and partitioned tables