Re: More stable query plans via more predictable column statistics - Mailing list pgsql-hackers

From Shulgin, Oleksandr
Subject Re: More stable query plans via more predictable column statistics
Date
Msg-id CACACo5Q-i9rzEsBrxGDpDqh7Wui40JvsTTLMEK2Fd+G2WbGuYA@mail.gmail.com
Whole thread Raw
In response to Re: More stable query plans via more predictable column statistics  ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>)
Responses Re: More stable query plans via more predictable column statistics
List pgsql-hackers
On Tue, Mar 15, 2016 at 4:47 PM, Shulgin, Oleksandr <oleksandr.shulgin@zalando.de> wrote:
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?

I've just seen that this patch doesn't have a reviewer assigned anymore...

I would welcome any review.  If we don't commit even the first part (bugfix) now, is it going to be 9.7-only material?..

--
Alex

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: VS 2015 support in src/tools/msvc
Next
From: Petr Jelinek
Date:
Subject: Re: WIP: Access method extendability