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
ср, 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
>
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
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
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
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
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
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
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
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.
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.
15 matches
Mail list logo