From: | James Coleman <jtc331(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Teach predtest about IS [NOT] <boolean> proofs |
Date: | 2024-04-01 12:06:42 |
Message-ID: | CAAaqYe9Cs6RttpMo1x0MdJKV9wxYJC5iknE6S7+5+dtY7q25Pg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 25, 2024 at 5:53 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> James Coleman <jtc331(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Borisov | 2024-04-01 12:11:10 | Re: Fix parameters order for relation_copy_for_cluster |
Previous Message | James Coleman | 2024-04-01 12:05:02 | Re: Teach predtest about IS [NOT] <boolean> proofs |