From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
Cc: | Aleksandr Parfenov <a(dot)parfenov(at)postgrespro(dot)ru>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Flexible configuration for full-text search |
Date: | 2018-08-23 22:13:46 |
Message-ID: | 13787.1535062426@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> writes:
> On Fri, Apr 6, 2018 at 10:52 AM Aleksandr Parfenov
> <a(dot)parfenov(at)postgrespro(dot)ru> wrote:
>> The key point of the patch is to process stopwords the same way as
>> others at the level of the PostgreSQL internals and give users an
>> instrument to process them in a special way via configurations.
> If we're going to do it that way by providing separate dictionaries
> for stop words, then I think we should also make it for builtin
> dictionaries and configurations. So, I think this patch should also
> split builtin dictionaries into stemmers and stop word dictionaries,
> and provide corresponding configuration over them. It would be also
> needed to perform some benchmarking to show that new way of defining
> configurations is not worse than previous way in the performance.
I'm hesitant about the backwards-compatibility aspects of this.
Yes, we could set up the standard text search configurations to still
work the same as before, but how will you do it without breaking existing
custom configurations that use those dictionaries?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2018-08-23 22:22:33 | Re: Make executor's Range Table an array instead of a List |
Previous Message | Alexander Korotkov | 2018-08-23 22:06:08 | Re: Flexible configuration for full-text search |