Re: BUG #16863: Assert failed in set_plain_rel_size() on processing ~* with a long prefix

Alexander Lakhin <exclusion(at)gmail(dot)com> writes:
> 12.02.2021 23:37, Tom Lane wrote:
>> Alexander Lakhin <exclusion(at)gmail(dot)com> writes:
>>> I've found a division that produces NaN:
>>> sel /= 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=# create table test (t text);
>> CREATE TABLE
>> regression=# explain SELECT * FROM test WHERE t ~* ('^' || repeat('-', 500));
>> ...
>> Seq Scan on test (cost=0.00..27.00 rows=10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104 width=32)

> 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