Re: BUG #16863: Assert failed in set_plain_rel_size() on processing ~* with a long prefix
От | Alexander Lakhin |
---|---|
Тема | Re: BUG #16863: Assert failed in set_plain_rel_size() on processing ~* with a long prefix |
Дата | |
Msg-id | 881ff073-daac-7946-cc66-c61dcfb5efa6@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #16863: Assert failed in set_plain_rel_size() on processing ~* with a long prefix (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #16863: Assert failed in set_plain_rel_size() on processing ~* with a long prefix
|
Список | pgsql-bugs |
Hello Tom, 12.02.2021 23:37, Tom Lane wrote: > Alexander Lakhin <exclusion@gmail.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=10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104width=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. (I've chosen the version 13.2 in the bug report, but it's really delayed somewhere.) Though that division produced a NaN for me on both branches. Best regards, Alexander
В списке pgsql-bugs по дате отправления: