Pavel Borisov writes:
> ср, 22 июл. 2020 г. в 19:10, Tom Lane :
>> The other issue we have to agree on is whether we want to sneak this
>> fix into v13, or wait another year for it. I feel like it's pretty
>> late to be making potentially API-breaking changes, but on the other
>> hand this is und
ср, 22 июл. 2020 г. в 19:10, Tom Lane :
> Pavel Borisov writes:
> > For 0002-remove-calc-not-flag.patch
> > The patch changes the behavior which is now considered default. This is
> true in RUM module and maybe in some other tsearch side modules. Applying
> the patch can make code more beautiful
Pavel Borisov writes:
> For 0002-remove-calc-not-flag.patch
> The patch changes the behavior which is now considered default. This is true
> in RUM module and maybe in some other tsearch side modules. Applying the
> patch can make code more beautiful but possibly will not give some
> performanc
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
Hi, all!
It seems that as of now we have two sets of patches for thi
Pavel Borisov writes:
> чт, 2 июл. 2020 г. в 19:38, Artur Zakirov :
>> So it seems we are losing some results with RUM as well.
> For me it is 100% predictable that unmodified RUM is still losing results
> as it is still using binary callback.
Right, that's in line with what I expected as well.
чт, 2 июл. 2020 г. в 19:38, Artur Zakirov :
> Hello,
>
> On Thu, Jul 2, 2020 at 8:23 PM Pavel Borisov
> wrote:
> >
> > ср, 1 июл. 2020 г. в 23:16, Tom Lane :
> >>
> >> Pavel Borisov writes:
> >> > Below is my variant how to patch Gin-Gist weights issue:
> >>
> >> I looked at this patch, but I'm
Hello,
On Thu, Jul 2, 2020 at 8:23 PM Pavel Borisov wrote:
>
> ср, 1 июл. 2020 г. в 23:16, Tom Lane :
>>
>> Pavel Borisov writes:
>> > Below is my variant how to patch Gin-Gist weights issue:
>>
>> I looked at this patch, but I'm unimpressed, because it's buggy.
>
>
> Thank you, i'd noticed and
ср, 1 июл. 2020 г. в 23:16, Tom Lane :
> Pavel Borisov writes:
> > Below is my variant how to patch Gin-Gist weights issue:
>
> I looked at this patch, but I'm unimpressed, because it's buggy.
>
Thank you, i'd noticed and made minor corrections in the patch. Now it
should work
correctly,
As for
Pavel Borisov writes:
> Below is my variant how to patch Gin-Gist weights issue:
I looked at this patch, but I'm unimpressed, because it's buggy.
You would have noticed if you'd included the test cases I wrote:
--- /home/postgres/pgsql/src/test/regress/expected/tsearch.out 2020-07-01 14:58
:56.
Hi All!
1. Generally the difference of my patch in comparison to Tom's patch 0001
is that I tried to move previous logic of GIN's own TS_execute_ternary() to
the general logic of TS_execute_recurse and in case we have index without
positions to avoid diving into phrase operator replacing (only in t
1. Really if it's possible to avoid bool callbacks at all and shift
everywhere to ternary it makes code quite beautiful and even. But I also
think we are still not obliged to drop support for (legacy or otherwise)
bool callbacks and also consistent functions form some old extensions (I
don't know f
Hi, all!
Below is my variant how to patch Gin-Gist weights issue:
1. First of all I propose to shift from previously Gin's own TS_execute
variant and leave only two: TS_execute with bool result and bool type
callback and ternary TS_execute_recurse with ternary callback. I suppose
all legacy consist
I wrote:
> I think the root of the problem is that if we have a query using
> weights, and we are testing tsvector data that lacks positions/weights,
> we can never say there's definitely a match. I don't see any decently
> clean way to fix this without redefining the TSExecuteCallback API
> to re
Pavel Borisov writes:
> It appeared than GIN index sometimes lose results if simultaneously:
> 1 if query operand contains weight marks
> 2 if weight-marked operand is negated by ! operator
> 3 if there are only logical (not phrase) operators from this negation
> towards the root of query tree.
N
Hi, all
It appeared than GIN index sometimes lose results if simultaneously:
1 if query operand contains weight marks
2 if weight-marked operand is negated by ! operator
3 if there are only logical (not phrase) operators from this negation
towards the root of query tree.
e.g. '!crew:A'::tsqu
15 matches
Mail list logo
