Re: Failed assertion clauses != NIL

From: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Tomas Vondra <tomas(dot)vondra(at)postgresql(dot)org>, Manuel Rigger <rigger(dot)manuel(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Failed assertion clauses != NIL
Date: 2019-11-19 14:38:42
Message-ID: 20191119143842.s2rrzdg43pvw3ael@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> On Tue, Nov 19, 2019 at 02:45:54PM +0100, Daniel Gustafsson wrote:
> > On 19 Nov 2019, at 14:38, Dmitry Dolgov <9erthalion6(at)gmail(dot)com> wrote:
> >
> >> On Tue, Nov 19, 2019 at 01:50:51PM +0100, Manuel Rigger wrote:
> >>
> >> when building PostgreSQL with -enable-cassert, executing the following
> >> statements result in an assertion error:
> >>
> >> CREATE TABLE t0(c0 boolean, c1 boolean, c2 boolean);
> >> INSERT INTO t0 VALUES(FALSE, FALSE, FALSE);
> >> CREATE STATISTICS s0 ON c0, c2 FROM t0;
> >> ANALYZE;
> >> SELECT * FROM t0 WHERE t0.c2 OR t0.c1 OR t0.c0;
> >
> > Yes, I can reproduce it too. mcv_get_match_bitmap expects that
> > stat_clauses will not be empty, but looks like in this situation
> > stat_clauses is indeed NIL. clauselist_selectivity_simple right before
> > actually doesn't insist on stat_clauses being non empty, probably it's
> > just too strict assert.
>
> I might be missing something, but if the clause list is NIL, wouldn't it better
> to exit earlier from statext_mcv_clauselist_selectivity rather than relax the
> Assertion since we will get a 1.0 estimate either way?
>
> cheers ./daniel
>
> --- a/src/backend/statistics/extended_stats.c
> +++ b/src/backend/statistics/extended_stats.c
> @@ -1267,6 +1267,9 @@ statext_mcv_clauselist_selectivity(PlannerInfo *root, List *clauses, int varReli
> listidx++;
> }
>
> + if (stat_clauses == NIL)
> + return 1.0;
> +
> /*
> * First compute "simple" selectivity, i.e. without the extended
> * statistics, and essentially assuming independence of the
>

Yep, seems like a reasonable thing to do, especially since it's already
like that in a few other places in this function.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tomas Vondra 2019-11-19 15:08:40 Re: Failed assertion clauses != NIL
Previous Message vignesh C 2019-11-19 14:34:04 initdb SegFault