From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ALTER TABLE ... ALTER COLUMN ... SET DISTINCT |
Date: | 2009-08-03 01:01:24 |
Message-ID: | 603c8f070908021801s36bc8b15p3300280c6f43412b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Aug 2, 2009 at 8:35 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-08-03 01:41:04 | CommitFest Status Summary - 2009-08-03 |
Previous Message | Robert Haas | 2009-08-03 00:50:08 | Re: machine-readable explain output v4 |