Re: Functional dependencies and GROUP BY

Поиск
Список
Период
Сортировка
Искать
От
Rob Wultsch
Тема
Re: Functional dependencies and GROUP BY
Дата
Msg-id
AANLkTimU-vwORPmb0cm0MYePbPrrbpdsjqHvfjIYd6o_@mail.gmail.com
Ответ на
Список
Дерево обсуждения
Functional dependencies and GROUP BY Peter Eisentraut <peter_e@gmx.net>
Re: Functional dependencies and GROUP BY Peter Eisentraut <peter_e@gmx.net>
Re: Functional dependencies and GROUP BY Alex Hunsaker <badalex@gmail.com>
Re: Functional dependencies and GROUP BY Peter Eisentraut <peter_e@gmx.net>
Re: Functional dependencies and GROUP BY Alex Hunsaker <badalex@gmail.com>
Re: Functional dependencies and GROUP BY Peter Eisentraut <peter_e@gmx.net>
Re: Functional dependencies and GROUP BY Alex Hunsaker <badalex@gmail.com>
Re: Functional dependencies and GROUP BY Peter Eisentraut <peter_e@gmx.net>
Re: Functional dependencies and GROUP BY Alex Hunsaker <badalex@gmail.com>
Re: Functional dependencies and GROUP BY Peter Eisentraut <peter_e@gmx.net>
Re: Functional dependencies and GROUP BY Tom Lane <tgl@sss.pgh.pa.us>
Re: Functional dependencies and GROUP BY Dean Rasheed <dean.a.rasheed@gmail.com>
Re: Functional dependencies and GROUP BY Tom Lane <tgl@sss.pgh.pa.us>
Re: Functional dependencies and GROUP BY Dean Rasheed <dean.a.rasheed@gmail.com>
Re: Functional dependencies and GROUP BY Tom Lane <tgl@sss.pgh.pa.us>
Re: Functional dependencies and GROUP BY Peter Eisentraut <peter_e@gmx.net>
Re: Functional dependencies and GROUP BY Alex Hunsaker <badalex@gmail.com>
Re: Functional dependencies and GROUP BY Alex Hunsaker <badalex@gmail.com>
Re: Functional dependencies and GROUP BY Alex Hunsaker <badalex@gmail.com>
Re: Functional dependencies and GROUP BY Stephen Frost <sfrost@snowman.net>
Re: Functional dependencies and GROUP BY Rob Wultsch <wultsch@gmail.com>
Re: Functional dependencies and GROUP BY Tom Lane <tgl@sss.pgh.pa.us>
Re: Functional dependencies and GROUP BY Greg Stark <gsstark@mit.edu>
Re: Functional dependencies and GROUP BY Tom Lane <tgl@sss.pgh.pa.us>
Re: Functional dependencies and GROUP BY Peter Eisentraut <peter_e@gmx.net>
Re: Functional dependencies and GROUP BY Stephen Frost <sfrost@snowman.net>
Re: Functional dependencies and GROUP BY Tom Lane <tgl@sss.pgh.pa.us>
Re: Functional dependencies and GROUP BY Stephen Frost <sfrost@snowman.net>
Re: Functional dependencies and GROUP BY Greg Stark <gsstark@mit.edu>
Re: Functional dependencies and GROUP BY Greg Stark <gsstark@mit.edu>
Re: Functional dependencies and GROUP BY Pavel Stehule <pavel.stehule@gmail.com>
Re: Functional dependencies and GROUP BY Hitoshi Harada <umi.tanuki@gmail.com>
Re: Functional dependencies and GROUP BY Peter Eisentraut <peter_e@gmx.net>
Re: Functional dependencies and GROUP BY Tom Lane <tgl@sss.pgh.pa.us>
Re: Functional dependencies and GROUP BY Peter Eisentraut <peter_e@gmx.net>
Re: Functional dependencies and GROUP BY Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>
Re: Functional dependencies and GROUP BY Greg Stark <gsstark@mit.edu>
Re: Functional dependencies and GROUP BY Stephen Frost <sfrost@snowman.net>
On Mon, Jun 7, 2010 at 6:41 PM, Stephen Frost  wrote:
> * Peter Eisentraut (peter_e@gmx.net) wrote:
>> This is frequently requested by MySQL converts (and possibly others).
>
> I'd certainly love to see it- but let's not confuse people by implying
> that it would actually act the way MySQL does.  It wouldn't, because
> what MySQL does is alot closer to 'distinct on' and is patently insane
> to boot.  Again, I'd *love* to see this be done in PG, but when we
> document it and tell people about it, *please* don't say it's similar in
> any way to MySQL's "oh, we'll just pick a random value from the columns
> that aren't group'd on" implementation.


Preface: I work as a MySQL DBA (yeah, yeah, laugh it up...).

It has been my experience that the vast majority of the time when a
MySQL users make use of the "fine feature" which allows them to use
unaggregated columns which is not present in the GROUP BY clause in an
aggregating query they have made an error because they do not
understand GROUP BY. I have found this lack of understanding to be
very wide spread across the MySQL developer and *DBA* communities. I
also would really hesitate to compare this useful feature to the *fine
feature* present in MySQL. Due to a long standing bug
(http://bugs.mysql.com/bug.php?id=8510) it really is not possible to
get MySQL to behave sanely. It is my impression that many programs of
significant size that interact with MySQL have errors because of this
issue and it would be good to not claim to have made Postgres
compatible.

That said, I imagine if this feature could make it into the Postgres
tree it would be very useful.

Would I be correct in assuming that while this feature would make
query planning more expensive, it would also often decrease the cost
of execution?

Best,

Rob Wultsch
wultsch@gmail.com

В списке pgsql-hackers по дате отправления
От: Teodor Sigaev
Дата:
Сообщение: PlPython bug in 9.0/8.4.4
От: Pierre C
Дата:
FAQ