Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ap3Rb-000555-Of for pgsql-performance@arkaria.postgresql.org; Sun, 10 Apr 2016 00:41:39 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1ap3Rb-0008MP-40 for pgsql-performance@arkaria.postgresql.org; Sun, 10 Apr 2016 00:41:39 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ap3Ra-0008Lz-58 for pgsql-performance@postgresql.org; Sun, 10 Apr 2016 00:41:38 +0000 Received: from mail-oi0-x244.google.com ([2607:f8b0:4003:c06::244]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1ap3RW-0007mX-Pf for pgsql-performance@postgresql.org; Sun, 10 Apr 2016 00:41:36 +0000 Received: by mail-oi0-x244.google.com with SMTP id v67so20279334oie.0 for ; Sat, 09 Apr 2016 17:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bowt-ie.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lSlOWbjYCsykCLza0z+ApJjjGD13HRGf7FHqpieFdYM=; b=orZU8SkUyKsgmyqUX9RR87fEjOqCEXoWWAUe7UlauRjftQQ92clQsBo9zgK3PFyGV9 pQ9cYk5QNo9d6d4tD8I36R3CGxCyk1H4A/ldp3i3pPRAA6tA5mMRnWOYCRBif1Czu08t 94hVYXWPOPnizb0ryizb/keAMHvCzvT0r2lXLNni1aqstHsqoMLgljqrNVFA0X20lEOL qX2nsgi43KG/+82bVUwC+Ntls+qx0921lkz26CKG1EUodaG2z0mZsrud5ccQgpT6CJGg m9wQTuiO3cN5eh6ffU2Rm7BaRd9XD2bEsyn2KU0ERD5/FQndsYMwdUqrFARAUMYHPwn4 l6Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=lSlOWbjYCsykCLza0z+ApJjjGD13HRGf7FHqpieFdYM=; b=B2WQz5RWwy9WGkBnZOP+brNCSs9/sjI8gN7/0Bja/Xn0r2JFgivhWg/HXBPotZc63W S5D3AJk6+l2bUVtAmoqTl8o3jcE11d88EeGAaQliJXz6JLMAJngbS+dDLnaKWohTQHxy YxdCkHUJTg0MOMifdn0Z7+yhZMUgXh+7GvJs2ZlFT9egA21EdUNw0jFpf8UP3CVGXoCq hRVQPWnlDuZEnVtVSjmGWvtBZZp9FB50ymDaLWktS7mKl63JezSiowON+jlUjhLfovLx wYcedNt5sRBnTM33BFp98D6hBXKuQbhgOJXKHf36tFC8rpSXHbYwYxODckj6N9Mx8EEJ 3Uow== X-Gm-Message-State: AD7BkJIBV4EU5+RZP1PkzkwkXwa0RHJVEM7kbONCWx43ntVtTKliypjRj1WYoYPVK7NlA+GLLcXPJYS6VtGg6A== X-Received: by 10.157.57.131 with SMTP id y3mr6502902otb.169.1460248893670; Sat, 09 Apr 2016 17:41:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.38.71 with HTTP; Sat, 9 Apr 2016 17:41:14 -0700 (PDT) X-Originating-IP: [142.254.51.113] In-Reply-To: <09FB46A1-B2CA-4C65-9959-D4D03C81EBB1@cogdon.org> References: <09FB46A1-B2CA-4C65-9959-D4D03C81EBB1@cogdon.org> From: Peter Geoghegan Date: Sat, 9 Apr 2016 17:41:14 -0700 Message-ID: Subject: Re: Adding a ROLLUP switches to GroupAggregate unexpectedly To: Chris Cogdon Cc: pgsql-performance@postgresql.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On Thu, Mar 31, 2016 at 10:03 AM, Chris Cogdon wrote: > Description: Adding a summary row by changing =E2=80=9CGROUP BY x=E2=80= =9D into =E2=80=9CGROUP BY > ROLLUP (x)=E2=80=9D should not cause a switch from HashAggregate to Group= Aggregate While this restriction has not been lifted for PostgreSQL 9.6, external sorting will be much faster in 9.6. During benchmarking, there were 2x-3x speedups in overall query runtime for many common cases. This new performance optimization should ameliorate your ROLLUP problem on 9.6, simply because the sort operation will be so much faster. Similarly, we have yet to make HashAggregates spill when they exceed work_mem, which is another restriction on their use that we should get around to fixing. As you point out, this restriction continues to be a major consideration during planning, sometimes resulting in a GroupAggregate where a HashAggregate would have been faster (even with spilling of the hash table). However, simply having significantly faster external sorts once again makes that restriction less of a problem. I have noticed that the old replacement selection algorithm that the external sort would have used here does quite badly on low cardinality inputs, too. I bet that was a factor here. --=20 Peter Geoghegan --=20 Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance