Re: ALTER TABLE ... ALTER COLUMN ... SET DISTINCT - Mailing list pgsql-hackers

From Robert Haas
Subject Re: ALTER TABLE ... ALTER COLUMN ... SET DISTINCT
Date
Msg-id 603c8f070908021801s36bc8b15p3300280c6f43412b@mail.gmail.com
Whole thread Raw
In response to Re: ALTER TABLE ... ALTER COLUMN ... SET DISTINCT  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, Aug 2, 2009 at 8:35 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Thanks.  The changes all look good - except I'm curious why %g vs. %f?
>
> So as not to add ".000000" unnecessarily.  Positive values for ndistinct
> should be treated as integers.  (I considered adding an error check to
> reject values like 20.5, but refrained...)

Oh, I see.  That makes sense.

I think we do entirely too much forcing things to integers in the
query planner as it is.  The fact that a value can't truly be
fractional doesn't mean that an estimate of the value can't be
fractional.

Now, in this particular case, it seems hard to imagine that 20.5 is a
very useful value.  But that's not really our problem: we just need to
reject illegal values, not useless ones.

I'm interested to see how useful this proves to be in the field.  I
implemented it mostly on a whim because you and others seemed to think
it could have some value, and because I get an unhealthy amount of
personal satisfaction out of writing code during my spare time.  But
the real test will be to see whether the real users who were getting
bad query plans as a result of poor ndistinct estimates are able to
make practical use of this feature to get better ones.

...Robert


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: machine-readable explain output v4
Next
From: Robert Haas
Date:
Subject: CommitFest Status Summary - 2009-08-03