Amit Langote writes:
> I too wasn't sure if the patch's modifications to
> operator_predicate_proof() led to correct handling for the case where both
> clause_const and pred_const are both NULL consts. ISTM that the result in
> that case becomes what operator_same_subexprs_proof() would return fo
On 2018/03/21 23:00, Tom Lane wrote:
> Emre Hasegeli writes:
>> I am not sure if we are covering the case when clause_const and
>> pred_const are both NULL. In this case, we should be able to return
>> true only by checking op_strict(pred_op) or maybe even without
>> checking that. Am I mistaken
> Yeah, that's there. We need both operators to be strict, I think;
> otherwise we can't really assume anything about what they'd return
> for NULL inputs. But if they are, we have NULL => NULL which is
> valid for all proof cases.
I understand. I don’t see any problems in this case.
Emre Hasegeli writes:
> I am not sure if we are covering the case when clause_const and
> pred_const are both NULL. In this case, we should be able to return
> true only by checking op_strict(pred_op) or maybe even without
> checking that. Am I mistaken?
Yeah, that's there. We need both operat
> After further thought, it seems like the place to deal with this is
> really operator_predicate_proof(), as in the attached draft patch
> against HEAD. This passes the smell test for me, in the sense that
> it's an arguably correct and general extension of the proof rules,
> but it could use mor
I wrote:
> After further thought, it seems like the place to deal with this is
> really operator_predicate_proof(), as in the attached draft patch
> against HEAD. This passes the smell test for me, in the sense that
> it's an arguably correct and general extension of the proof rules,
> but it coul
On 2018/03/14 17:16, Amit Langote wrote:
> On 2018/03/10 13:40, Tom Lane wrote:
>> I wrote:
>>> I think it'd make more sense to see about incorporating that idea in
>>> predicate_implied_by_simple_clause/predicate_refuted_by_simple_clause.
>>
>> After further thought, it seems like the place to dea
On 2018/03/10 13:40, Tom Lane wrote:
> I wrote:
>> I think it'd make more sense to see about incorporating that idea in
>> predicate_implied_by_simple_clause/predicate_refuted_by_simple_clause.
>
> After further thought, it seems like the place to deal with this is
> really operator_predicate_proo
I wrote:
> I think it'd make more sense to see about incorporating that idea in
> predicate_implied_by_simple_clause/predicate_refuted_by_simple_clause.
After further thought, it seems like the place to deal with this is
really operator_predicate_proof(), as in the attached draft patch
against HEA
Amit Langote writes:
> [ v4-0001-Disregard-nulls-in-SAOP-rightarg-array-list-durin.patch ]
This patch seems pretty wrong to me. The proposed proof rule is wrong
for !useOr expressions (that is, "scalar op ALL (array)"); you can't
just ignore null items in that case. It's also wrong when we need
On 2018/03/06 19:16, Emre Hasegeli wrote:
>> Hmm, state->next refers to two different pointer values on line 1 and line
>> 2. It may end up being set to NULL on line 1. Am I missing something?
>
> True, lnext(state->next) can set it to NULL. I confused by the below
> code on the same function d
> Hmm, state->next refers to two different pointer values on line 1 and line
> 2. It may end up being set to NULL on line 1. Am I missing something?
True, lnext(state->next) can set it to NULL. I confused by the below
code on the same function doing the steps in reverse order. With this
cleare
On 2018/03/06 18:46, Emre Hasegeli wrote:
>> Patch teaches it to ignore nulls when it's known that the operator being
>> used is strict. It is harmless and has the benefit that constraint
>> exclusion gives an answer that is consistent with what actually running
>> such a qual against a table's ro
> Patch teaches it to ignore nulls when it's known that the operator being
> used is strict. It is harmless and has the benefit that constraint
> exclusion gives an answer that is consistent with what actually running
> such a qual against a table's rows would do.
Yes, I understood that. I just
Hi.
Thanks for reviewing again.
On 2018/03/05 23:04, Emre Hasegeli wrote:
>>> Shouldn't we check if we consumed all elements (state->next_elem >=
>>> state->num_elems) inside the while loop?
>>
>> You're right. Fixed.
>
> I don't think the fix is correct. arrayconst_next_fn() can still
> execu
>> Shouldn't we check if we consumed all elements (state->next_elem >=
>> state->num_elems) inside the while loop?
>
> You're right. Fixed.
I don't think the fix is correct. arrayconst_next_fn() can still
execute state->next_elem++ without checking if we consumed all
elements. I couldn't manage
Hi.
On 2018/03/04 22:12, Emre Hasegeli wrote:
>> Yeah, the patch in its current form is wrong, because it will give wrong
>> answers if the operator being used in a SAOP is non-strict. I modified
>> the patch to consider operator strictness before doing anything with nulls.
>
> I tried to review
> Yeah, the patch in its current form is wrong, because it will give wrong
> answers if the operator being used in a SAOP is non-strict. I modified
> the patch to consider operator strictness before doing anything with nulls.
I tried to review this patch without any familiarity to the code.
arra
On Sun, Feb 4, 2018 at 11:20 PM, Ashutosh Bapat
wrote:
> On Thu, Feb 1, 2018 at 2:23 PM, Amit Langote
> wrote:
>> Yeah, the patch in its current form is wrong, because it will give wrong
>> answers if the operator being used in a SAOP is non-strict. I modified
>> the patch to consider operator s
On 2018/02/05 13:20, Ashutosh Bapat wrote:
> On Thu, Feb 1, 2018 at 2:23 PM, Amit Langote
> wrote:
>>
>> Yeah, the patch in its current form is wrong, because it will give wrong
>> answers if the operator being used in a SAOP is non-strict. I modified
>> the patch to consider operator strictness
On Thu, Feb 1, 2018 at 2:23 PM, Amit Langote
wrote:
>
> Yeah, the patch in its current form is wrong, because it will give wrong
> answers if the operator being used in a SAOP is non-strict. I modified
> the patch to consider operator strictness before doing anything with nulls.
That's fine, but
Thanks for the comments.
On 2018/02/01 16:40, Ashutosh Bapat wrote:
> On Thu, Feb 1, 2018 at 12:26 PM, Amit Langote
> wrote:
>> Hi.
>>
>> When addressing a review comment on the fast partition pruning thread [1],
>> I noticed that specifying null in the IN-list will cause constraint
>> exclusion
On Thu, Feb 1, 2018 at 12:26 PM, Amit Langote
wrote:
> Hi.
>
> When addressing a review comment on the fast partition pruning thread [1],
> I noticed that specifying null in the IN-list will cause constraint
> exclusion to wrongly fail to refute a table's check predicate.
>
> create table foo (a i
23 matches
Mail list logo
