Re: [HACKERS] Remove 1MB size limit in tsvector

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

In response to

Browse pgsql-hackers by date

  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)