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 1jj56B-0001vI-38 for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Jun 2020 18:05:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jj56A-0004nu-1Y for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Jun 2020 18:05:14 +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 1jj53Z-0005Hr-R1 for pgsql-hackers@lists.postgresql.org; Wed, 10 Jun 2020 18:02:33 +0000 Received: from mail-pf1-x433.google.com ([2607:f8b0:4864:20::433]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jj4gz-0004wV-5K for pgsql-hackers@postgresql.org; Wed, 10 Jun 2020 17:39:14 +0000 Received: by mail-pf1-x433.google.com with SMTP id a127so1390765pfa.12 for ; Wed, 10 Jun 2020 10:39:13 -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=Lgj1q0ukwO72q4fJ+ZxUuPrVWTb8IiNw3vVAUUarTys=; b=OGqFYccFF/+3bSTCJaJ+el5KoD9QfQXAQPesn6rFohqu7bjwbGAP024RsCbsaUvlOd wETwwQ7glO4phTEFdfJgpCH1094nlPrQP7gUUBSTuTfF6fxfKbsIVdQOwqrrbhPsn+38 yB397t/OXfd1E3Fulr7NpmpLL0331x0NnXD2eUAfTAClFJT6xaNBk1fgAem6cOqkXW91 0GCnwhq+Nt5oW6SpZHNN10qaF3tnz4EBaF3IfQaKrWeTPft+MAuNq21GskCIIsrUdNA8 Q0HcuSMJO/0g9iQYyvtNteg6f2vLNBFUnoP4jFv7AjIMKSbHLPWuryMfmlQLXFowlTnh BlBg== 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=Lgj1q0ukwO72q4fJ+ZxUuPrVWTb8IiNw3vVAUUarTys=; b=a+2uVRRU9acBWwv4PG0qh8HR9djiwnECMcR4qNHXKUgPjQg9Ux3+PnlHrFt908T/s2 3lvq3rFtkrDhiW7uSmtepgCvYVPOv5ISlplk5EXBwIU70ooXpb3blmbEsQZ6lnvfR4nv L6i1ugirWweJaQWBT2nQLwWyBY/paF2kpiZxdHBg/bFtqKVbyMCFoQciggRgw1hvUeWN 1iuSeeq2F8z23OEX2SGKNf0DprBQ92aMBUn4SDoFn6lW/V7qPDRkxfSvDn5vQ/TuBNSC cBP61l+iIC75mWdrKBt2FfOgdzgxm/8/q3a5x3GkhWEhrWPLcTV5A58BA0BWRx9ojc/Q Adug== X-Gm-Message-State: AOAM531Uno3TnGZAEE6N2MLPB5umPk7/gAHv9TNIDlG4Wsqa9zrCYwn0 s4LgJSX9aJfoiX+D68A3DbzMBg== X-Google-Smtp-Source: ABdhPJw89DI8FupRCbJ1NJ+woLvbz9UrUb1QB6HiKXQrVTlwDWX4K1UckqAwsTuiyJ5p1l54mfT3qw== X-Received: by 2002:a62:bd07:: with SMTP id a7mr3570203pff.311.1591810752093; Wed, 10 Jun 2020 10:39:12 -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 n69sm393176pjc.25.2020.06.10.10.39.09 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 10 Jun 2020 10:39:10 -0700 (PDT) Message-ID: <87a16031a58db0c4ba4bb506f2919dea8948d7b0.camel@j-davis.com> Subject: Re: Default setting for enable_hashagg_disk From: Jeff Davis To: Melanie Plageman Cc: Robert Haas , Tomas Vondra , Justin Pryzby , "pgsql-hackers@postgresql.org" Date: Wed, 10 Jun 2020 10:39:08 -0700 In-Reply-To: References: <9d9d1e1252a52ea1bad84ea40dbebfd54e672a0f.camel@j-davis.com> <20200407223900.GT2228@telsasoft.com> <20200409114855.h4hh7e2wt77p56sv@development> <6292f5a766198d5745eb8cc17ac736366056671d.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 Tue, 2020-06-09 at 18:20 -0700, Melanie Plageman wrote: > So, I was catching up on email and noticed the last email in this > thread. > > I think I am not fully understanding what > enable_groupingsets_hash_disk > does. Is it only for testing? It's mostly for testing. I could imagine cases where it would be useful to force groupingsets to use the disk, but I mainly wanted the setting there for testing the grouping sets hash disk code path. > Using the tests you added to src/test/regress/sql/groupingsets.sql, I > did get a plan that looks like hashagg is spilling to disk (goes > through I had something that worked as a test for a while, but then when I tweaked the costing, it started using the Sort path (therefore not testing my grouping sets hash disk code at all) and a bug crept in. So I thought it would be best to have a more forceful knob. Perhaps I should just get rid of that GUC and use the stats trick? Regards, Jeff Davis