Re: ALTER TABLE ... ALTER COLUMN ... SET DISTINCT
От | Robert Haas |
---|---|
Тема | Re: ALTER TABLE ... ALTER COLUMN ... SET DISTINCT |
Дата | |
Msg-id | 603c8f070904060324q5813f0ccpe5eab3996d0fdeb5@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ALTER TABLE ... ALTER COLUMN ... SET DISTINCT (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ALTER TABLE ... ALTER COLUMN ... SET DISTINCT
Re: ALTER TABLE ... ALTER COLUMN ... SET DISTINCT |
Список | pgsql-hackers |
On Sun, Apr 5, 2009 at 11:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> (It's also worth pointing out that the calculations we do with >> ndistinct are pretty approximations anyway. If the difference between >> stadistinct = -1 x 10^-6 and stadistinct = -1.4^10-6 is the thing >> that's determining whether the planner is picking the correct plan on >> your 4-billion-row table, > > No, it's the loss of ability to set stadistinct to -1e-9 or -1e-12 or > -1e-15 or so that is bothering me. In a table with billions of rows > that could become important. > > Or maybe not; but the real bottom line here is that it is 100% silly to > use a different representation in this column than is used in the > underlying stadistinct column. All you accomplish by that is to impose > on the user the intersection of the accuracy/range limits of the two > different representations. Well, I think I was pretty clear about what I was trying to accomplish. I think there are more people who care about pg_dump output being diffable than there are who need to set ndistinct more accurately than 1 ppm and yet not as an integer. Perhaps if any of those people are reading this thread they could chime in. Otherwise, I will implement as you propose. ...Robert
В списке pgsql-hackers по дате отправления: