Re: Bogus ANALYZE results for an otherwise-unique column with many nulls - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bogus ANALYZE results for an otherwise-unique column with many nulls
Date
Msg-id 24135.1470587756@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bogus ANALYZE results for an otherwise-unique column with many nulls  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: Bogus ANALYZE results for an otherwise-unique column with many nulls  (Andreas Joseph Krogh <andreas@visena.com>)
List pgsql-hackers
Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> On 5 August 2016 at 21:48, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> OK, thanks.  What shall we do about Andreas' request to back-patch this?
>> I'm personally willing to do it, but there is the old bugaboo of "maybe
>> it will destabilize a plan that someone is happy with".

> My inclination would be to back-patch it because arguably it's a
> bug-fix -- at the very least the old behaviour didn't match the docs
> for stadistinct:

Yeah.  I suspect that situations like this are pretty rare, or we'd have
recognized the problem sooner.  And at least for Andreas, it'd be fixing
a real problem.  I'll apply the back-patch unless I hear objections in
the next couple of hours.

> Additionally, I think that example is misleading because it's only
> really true if there are no null values in the column. Perhaps it
> would help to have a more explicit example to illustrate how nulls
> affect stadistinct, for example:

Good idea, will do.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Consolidate 'unique array values' logic into a reusable function?
Next
From: Bruce Momjian
Date:
Subject: Re: Heap WARM Tuples - Design Draft