Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jnQHW-0006tK-K0 for pgsql-hackers@arkaria.postgresql.org; Mon, 22 Jun 2020 17:30:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jnQHU-0000dh-9q for pgsql-hackers@arkaria.postgresql.org; Mon, 22 Jun 2020 17:30:52 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jnQHT-0000da-Vv for pgsql-hackers@lists.postgresql.org; Mon, 22 Jun 2020 17:30:52 +0000 Received: from mail-pj1-x1035.google.com ([2607:f8b0:4864:20::1035]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jnQHQ-0001US-NS for pgsql-hackers@postgresql.org; Mon, 22 Jun 2020 17:30:50 +0000 Received: by mail-pj1-x1035.google.com with SMTP id h95so137166pje.4 for ; Mon, 22 Jun 2020 10:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=v6hyU6DlR8yXJhgwDTjKb/nkssaX5NgMqooAtW/mVdQ=; b=VFXO9RlNirgHjIFV5goJJXBYZoB2I6MnTLEDQWgLLXIVnBt7VbNoyKaWJmSjdfT2XQ X8PvJdQJ1//C3DnkcjM24aExZKO9oYCPLcdHyNfGpwZms1SUISuARe3uV4/iGwSVeBcU JIrY90qW+3u9yif+c+JgvBYBjRp1TXLgwLfVw988eGwja3Wk6mu112aB8gNI+slwc6tG aCO50YCEJ9n/pB/cEUwy/ojPmuP7euEwMktRIPvdBcda9aiU4oVZ97PMSa3HaVpjUFki Nz06bVgAFxW8p7gH4aPRFO5J5dicyKQDY3KbJnQ+pHgzBK5yFV1jHLukE6dQkr4zO/n9 xf6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=v6hyU6DlR8yXJhgwDTjKb/nkssaX5NgMqooAtW/mVdQ=; b=c8JWT/pjPeAkrOZXWIxdqguAEdCRYqvaOT2eTTWk0Xi2lPFYjosm/Pukmg2d3yA0MR +x0SAdeAy2J+M8PErcVpwP/55Km+0/jKl2Q51uE3ciuB9bSOVwbKPOZbgW7TTQc61AWV ASopLxSX8VDh1clh4nW5Cly15ZHi2WMOzNTdv3pQfLHNMqai3RyL9eSO9S973vniCLKm 47glz6HjFXbSEXcNVuL0REB+C5rntQRw7ul/xgDOHcf86HxHtLlsgs6ygESffyDlIHey aYkKVneg9+m3K2Qkl886Cq6G7toj+aZ6Cr8HrIFphScgpHasZNK0MM3hkaHSbglRp+73 WtCA== X-Gm-Message-State: AOAM533UY2xmCqY5uOn4k+XSn/lX7/exHjtcc3zsKVv4lejB4jI90f+J tLcUWt0pF8GIsEr0W2lipM+0XQ== X-Google-Smtp-Source: ABdhPJw266qi8p0iOUoENwQehf2NC1VezVK8y+niKDOnOpG3hg6yU6IZMDJ13JzhEJHVXAkgHD8lfQ== X-Received: by 2002:a17:902:7c87:: with SMTP id y7mr842503pll.240.1592847047118; Mon, 22 Jun 2020 10:30:47 -0700 (PDT) Received: from jdavis.lan (c-73-231-146-4.hsd1.ca.comcast.net. [73.231.146.4]) by smtp.gmail.com with ESMTPSA id n69sm140221pjc.25.2020.06.22.10.30.45 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 22 Jun 2020 10:30:45 -0700 (PDT) Message-ID: Subject: Re: Default setting for enable_hashagg_disk From: Jeff Davis To: Robert Haas Cc: Justin Pryzby , Melanie Plageman , Tomas Vondra , "pgsql-hackers@postgresql.org" Date: Mon, 22 Jun 2020 10:30:43 -0700 In-Reply-To: References: <9d9d1e1252a52ea1bad84ea40dbebfd54e672a0f.camel@j-davis.com> <20200407223900.GT2228@telsasoft.com> <20200409114855.h4hh7e2wt77p56sv@development> <6292f5a766198d5745eb8cc17ac736366056671d.camel@j-davis.com> <20200610021544.GA14879@telsasoft.com> <8bff2e4e8020c3caa16b61a46918d21b573eaf78.camel@j-davis.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Mon, 2020-06-22 at 10:52 -0400, Robert Haas wrote: > So I feel like the really important thing here is to fix the cases > that don't come out well with default settings. ...with the caveat that perfection is not something to expect from our planner. > If we can't do that, > then the feature is half-baked and maybe should not have been > committed in the first place. HashAgg started out half-baked at the dawn of time, and stayed that way through version 12. Disk-based HashAgg was designed to fix it. Other major planner features generally offer a way to turn them off (e.g. parallelism, JIT), and we don't call those half-baked. I agree that the single GUC added in v13 (hashagg_avoid_disk_plan) is weird because it's half of a disable switch. But it's not weird because of my changes in v13; it's weird because the planner behavior in v12 was weird. I hope not many people need to set it, and I hope we can remove it soon. If you think we will never be able to remove the GUC, then we should think a little harder about whether we really need it. I am open to that discussion, but I don't think the presence of this GUC implies that disk-based hashagg is half-baked. Regards, Jeff Davis