Re: More stable query plans via more predictable column statistics
От | Shulgin, Oleksandr |
---|---|
Тема | Re: More stable query plans via more predictable column statistics |
Дата | |
Msg-id | CACACo5QapmaafTq8k0Zk0nS6Hx1iHzeQL+1m57-FMm=8mPzeJQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: More stable query plans via more predictable column statistics (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: More stable query plans via more predictable column statistics
|
Список | pgsql-hackers |
On Wed, Mar 9, 2016 at 5:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de> writes:
> Yes, I now recall that my actual concern was that sample_cnt may calculate
> to 0 due to the latest condition above, but that also implies track_cnt ==
> 0, and then we have a for loop there which will not run at all due to this,
> so I figured we can avoid calculating avgcount and running the loop
> altogether with that check. I'm not opposed to changing the condition if
> that makes the code easier to understand (or dropping it altogether if
> calculating 0/0 is believed to be harmless anyway).
Avoiding intentional zero divides is good. It might happen to work
conveniently on your machine, but I wouldn't think it's portable.
Tom,
Thank you for volunteering to review this patch!
Are you waiting on me to produce an updated version with more comments about NULL-handling in the distinct estimator, or do you have something cooking already?
--
Regards,
Alex
В списке pgsql-hackers по дате отправления: