On 31 March 2016 at 20:18, Tom Lane <t...@sss.pgh.pa.us> wrote: > Also, I wonder if it'd be a good idea to provide a guard against division > by zero --- we know rel->tuples > 0 at this point, but I'm less sure that > reldistinct can't be zero. In the same vein, I'm worried about the first > argument of pow() being slightly negative due to roundoff error, leading > to a NaN result.
Yeah, that makes sense. In fact, if we only apply the adjustment when reldistinct > 0 and rel->rows < rel->tuples, and rewrite the first argument to pow() as (rel->tuples - rel->rows) / rel->tuples, then it is guaranteed to be non-negative. If rel->rows >= rel->tuples (not sure if it can be greater), then we just want the original reldistinct. > Maybe we should also consider clamping the final reldistinct estimate to > an integer with clamp_row_est(). The existing code doesn't do that but > it seems like a good idea on general principles. OK, that seems sensible. Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
