From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Remove 1MB size limit in tsvector |
Date: | 2017-11-30 04:02:11 |
Message-ID: | CAB7nPqRW1d3rcWd5syatSPWbMedhD8FDnxo5-JrmoQdC5wFVQQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Sep 11, 2017 at 9:51 PM, Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> On 09/11/2017 01:54 PM, Robert Haas wrote:
>> On Mon, Sep 11, 2017 at 5:33 AM, Ildus Kurbangaliev
>> <i(dot)kurbangaliev(at)postgrespro(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-11-30 04:07:46 | Re: [HACKERS] INSERT ON CONFLICT and partitioned tables |
Previous Message | Michael Paquier | 2017-11-30 03:59:27 | Re: [HACKERS] [PATCH] Pattern based listeners for asynchronous messaging (LISTEN/NOTIFY) |