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 CACACo5RXQ3WPBFjxtKuDzrQOG4qBtZnzEV2JgKSuiLwmepshgg@mail.gmail.com
Whole thread Raw
In response to Re: More stable query plans via more predictable column statistics  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: More stable query plans via more predictable column statistics
List pgsql-hackers
On Tue, Mar 8, 2016 at 8:16 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
Shulgin, Oleksandr wrote:

> Alright.  I'm attaching the latest version of this patch split in two
> parts: the first one is NULLs-related bugfix and the second is the
> "improvement" part, which applies on top of the first one.

I went over patch 0001 and it seems pretty reasonable.  It's missing
some comment updates -- at least the large comments that talk about Duj1
should be modified to indicate why the code is now subtracting the null
count.

Good point.
 
Also, I can't quite figure out why the "else" now in line 2131
is now "else if track_cnt != 0".  What happens if track_cnt is zero?
The comment above the "if" block doesn't provide any guidance.

It is there only to avoid potentially dividing zero by zero when calculating avgcount (which will not be used after that anyway).  I agree it deserves a comment.

Thank you!
--
Alex

pgsql-hackers by date:

Previous
From: 李海龙
Date:
Subject: the include-timestamp data returned by pg_logical_slot_peek_changes() is always 2000-01-01 in 9.5.1
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission denied”