Pivotal Labs

Main menu

Skip to primary content
Skip to secondary content
  • About
  • Case Studies
  • Team
    • Executives
    • Locations
      • San Francisco (HQ)
      • Boston
      • Boulder
      • Denver
      • London
      • Los Angeles
      • New York
  • Community
    • Blogs
    • Tech Talks
    • Events
  • Careers
    • Lifestyle
    • Principles & Practices
    • Benefits
    • FAQ
    • Apply
  • Contact
    • Press Room
    • Press Releases
    • In The News
    • Press Kit
  • All
  • Labs
  • Standup
  • Tracker

No really, you have to pick *one*

Onsi Fakhouri
Tuesday, November 29, 2011

Ask for Help

“Postgres SELECT * GROUP BY insists that all selected fields must either appear in the GROUP BY or be aggregated.”

Many agreed that this is, in fact, how a database should behave and that MySQL’s leniency on this matter is faulty. If you select a field that you don’t group by, you must tell Postgres how to combine the sub-set of values that fall in a given group into a single result (should it take the max? the min? the mean? the most purple?).

  • 0 Shares
  • Share on Facebook
  • Share on Twitter

6 Comments

  1. Joseph Palermo says:

    Yes, MySQL is incorrect from a logical perspective, but it is decidedly more convenient.

    If I am grouping by users.id and also selecting users.*, other databases force me to also group by every column in the users table. This is not only inconvenient, but will also break as soon as the schema for the users table changes.

    If I could group by users.*, it would be better, but you can’t do that.

    I don’t know how much extra work it is, but I’d imagine grouping by a single column and then picking the first record for every other column is going to be a lot faster than grouping by a dozen or so columns. Databases may detect that and optimize for it though.

    If you really dislike the MySQL behavior, you can always enable the ONLY_FULL_GROUP_BY option, which makes it behave like everybody else. Personally though, MySQL’s behavior has never caused me a problem, and probably saved me a bit of pain and grief.

    November 29, 2011 at 11:17 am

  2. Joe Van Dyk says:

    This changed in 9.1, I think.

    SELECT count(*), entity_name, entity_address as address
    FROM entities JOIN employees using (entity_name)
    GROUP BY entity_name;

    count | entity_name | address
    ——-+————-+———-
    2 | HR | address1
    2 | SALES | address2

    November 29, 2011 at 2:02 pm

  3. Joe Van Dyk says:

    Here it is in action: https://gist.github.com/1407737

    So, I think the answer is really: “Upgrade to postgresql 9.1.” :-)

    November 29, 2011 at 6:41 pm

  4. Joe Van Dyk says:

    Of course, this assumes that you are grouping by something unique.

    November 29, 2011 at 6:52 pm

  5. Joe Van Dyk says:

    Oops, you have to group by the primary key. For whatever reason, grouping by something unique and not null doesn’t work.

    November 29, 2011 at 7:08 pm

  6. Alex says:

    If you don’t need to support mysql in app, you should use window function for such grouping.
    http://www.postgresql.org/docs/9.1/static/tutorial-window.html

    December 1, 2011 at 12:42 am

Add New Comment Cancel reply

Your email address will not be published.

Onsi Fakhouri

Onsi Fakhouri
San Francisco

Recent Posts

  • Cocktail: DRY up your backbone code with mixins
  • Coccyx: plug up those backbone leaks
  • [SF] Standup 4/26/2012: Hush Terminal, Hush
Subscribe to Onsi's Feed

Author Topics

backbone (2)
javascript (2)
agile (12)
  • About
  • Case Studies
  • Team
  • Community
  • Careers
  • Contact
  • Labs
  • Events

Contact Us

contact@pivotallabs.com
+1 415-77-PIVOT
TwitterLinkedInFacebook

Pivotal Tracker

Tracker is the award-winning agile project management tool that enables real-time collaboration around a shared, prioritized backlog.
Visit pivotaltracker.com >