Re: Failed assertion clauses != NIL - Mailing list pgsql-bugs

From Dean Rasheed
Subject Re: Failed assertion clauses != NIL
Date
Msg-id CAEZATCXXF82RXJzUZATPo3OsKn137ojxNSz83LgsxhDhzVmVjg@mail.gmail.com
Whole thread Raw
In response to Re: Failed assertion clauses != NIL  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: Failed assertion clauses != NIL  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-bugs
On Tue, 19 Nov 2019 at 15:08, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
>
> Yes, adding the condition to statext_mcv_clauselist_selectivity() would
> make this go away, and it's about the  simplest solution.
>

It's probably worth going a little further, and verifying that
stat_clauses references at least two attributes. We do that further up
for the original clause list, but it may not be true for the filtered
list. For example, given a WHERE clause like

  c0 > 0 AND c0 < 10 AND (c0 = 0 OR c1 = 1 OR c2 = 2)

and stats on (c0, c1), stat_clauses would include the first 2 clauses,
but they only reference 1 column, so it would be preferable to not use
the multivariate stats in that case.


> Ideally, we'd be able to improve the statistics matching to recognize
> it has to match all three attributes to match the clause, which in this
> case would mean the OR clause is passed to clause_selectivity, and we do
> some magic with extended statistics there.
>
> I'll see how complex / backpatchable that would be.
>

Yes, that seems like a worthwhile thing to do, but I think it goes
beyond what would normally be back-patched. It would really be a
feature enhancement rather than a bug fix.

Regards,
Dean



pgsql-bugs by date:

Previous
From: Ondřej Jirman
Date:
Subject: Re: BUG #16129: Segfault in tts_virtual_materialize in logicalreplication worker
Next
From: Ondřej Jirman
Date:
Subject: Re: BUG #16129: Segfault in tts_virtual_materialize in logicalreplication worker