Re: Teach predtest about IS [NOT] proofs - Mailing list pgsql-hackers

From James Coleman
Subject Re: Teach predtest about IS [NOT] proofs
Date
Msg-id CAAaqYe9Cs6RttpMo1x0MdJKV9wxYJC5iknE6S7+5+dtY7q25Pg@mail.gmail.com
Whole thread Raw
In response to Re: Teach predtest about IS [NOT] proofs  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Teach predtest about IS [NOT] proofs
List pgsql-hackers
On Mon, Mar 25, 2024 at 5:53 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> James Coleman <jtc331@gmail.com> writes:
> > [ v6 patchset ]
>
> I went ahead and committed 0001 after one more round of review
>
> statements; my bad).  I also added the changes in test_predtest.c from
> 0002.  I attach a rebased version of 0002, as well as 0003 which isn't
> changed, mainly to keep the cfbot happy.
>
> I'm still not happy with what you did in predicate_refuted_by_recurse:
> it feels wrong and rather expensively so.  There has to be a better
> way.  Maybe strong vs. weak isn't quite the right formulation for
> refutation tests?

Possibly. Earlier I'd mused that:

> Alternatively (to avoid unnecessary CPU burn) we could modify
> predicate_implied_by_recurse (and functionals called by it) to have a
> argument beyond "weak = true/false" Ie.g., an enum that allows for
> something like "WEAK", "STRONG", and "EITHER". That's a bigger change,
> so I didn't want to do that right away unless there was agreement on
> that direction.

I'm going to try implementing that and see how I feel about what it
looks like in practice.

Regards,
James Coleman



pgsql-hackers by date:

Previous
From: James Coleman
Date:
Subject: Re: Teach predtest about IS [NOT] proofs
Next
From: Pavel Borisov
Date:
Subject: Re: Fix parameters order for relation_copy_for_cluster