From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Lakhin <exclusion@gmail.com>
cc: pgsql-bugs@lists.postgresql.org, David Rowley <dgrowleyml@gmail.com>
Subject: Re: BUG #16863: Assert failed in set_plain_rel_size() on processing
 ~* with a long prefix
In-reply-to: <881ff073-daac-7946-cc66-c61dcfb5efa6@gmail.com>
References: <16863-35bf75b1b5ee4032@postgresql.org>
 <6de0a0c3-ada9-cd0c-3e4e-2fa9964b41e3@gmail.com>
 <1578689.1613162261@sss.pgh.pa.us>
 <881ff073-daac-7946-cc66-c61dcfb5efa6@gmail.com>
Comments: In-reply-to Alexander Lakhin <exclusion@gmail.com>
	message dated "Sat, 13 Feb 2021 00:00:00 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1607555.1613165924.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 12 Feb 2021 16:38:44 -0500
Message-ID: <1607556.1613165924@sss.pgh.pa.us>
Precedence: bulk

Alexander Lakhin <exclusion@gmail.com> writes:
> 12.02.2021 23:37, Tom Lane wrote:
>> Alexander Lakhin <exclusion@gmail.com> writes:
>>> I've found a division that produces NaN:
>>> sel /=3D pow(FIXED_CHAR_SEL, fixed_prefix_len);

>> Hmm.  I'm not getting a NaN AFAICT, but I am getting pretty darn weird
>> estimates.  I agree this needs some kind of clamp.
>> =

>> regression=3D# create table test (t text);
>> CREATE TABLE
>> regression=3D# explain SELECT * FROM test WHERE t ~* ('^' || repeat('-'=
, 500));
>> ...
>> Seq Scan on test  (cost=3D0.00..27.00 rows=3D10000000000000000159028911=
09759918046836080856394528138978132755774783877217038106081346998585681510=
4 width=3D32)

> The same number I've seen on the master branch. But on REL_13_STABLE I
> get a NaN and then the assertion failure.

The difference in behavior is evidently explained by commit a90c950fc,
which has decided to insert a random number in place of a NaN estimate.

Well, it's not really random, it's supposed to be 1e100 ... but EXPLAIN
doesn't know there's only 16 or so significant digits there.  Maybe we
need to work a bit harder on making that print nicely.  And maybe we
should rethink the idea that it's okay to gloss over a NaN estimate
that way.  I certainly don't see a defensible reason for assuming that
NaN means "a large value".

			regards, tom lane