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 1joUxU-0001jW-NW for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Jun 2020 16:42:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1joUxT-0002w2-KD for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Jun 2020 16:42:39 +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 1joUxT-0002vv-Dc for pgsql-hackers@lists.postgresql.org; Thu, 25 Jun 2020 16:42:39 +0000 Received: from mail-pf1-x441.google.com ([2607:f8b0:4864:20::441]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1joUxR-00083s-Gd for pgsql-hackers@postgresql.org; Thu, 25 Jun 2020 16:42:38 +0000 Received: by mail-pf1-x441.google.com with SMTP id 207so3082729pfu.3 for ; Thu, 25 Jun 2020 09:42:37 -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=9oxp53OfX8811D+8Nu35yjV3PTqlDL+2TKJO6XEbQyM=; b=UPFVQizyHlBfnlq6UifQxCJpb8rDGg21wRAmZz21b2G6KKuniI47kbQHs/PdGY/YFr LkNDQfRpfRw44ATNJ+fV4zy5eHAwFa5VvDRjX7X01UhaLnfUMDOMOzen8EoSX9JgEKUB ItfoHzvA5xIh1ibpocUkssnagrWODX/+mMtbt1e/EwFhmXmWlmCQpveIH2Iy4VCFZtOM CrFyOvB4haVdsMFLPHo/xgTeUOLSyjqE7xsEBPUi3i+ySXhNa7P7w/57+eDO9gORRKbl UsSYYuua6esIic7bqFm1ldjuS3DOm42Vedxtwy94Z6/+O5a0isNq2LrPTKDBwJxQE1la auZA== 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=9oxp53OfX8811D+8Nu35yjV3PTqlDL+2TKJO6XEbQyM=; b=IVls02eRyQDXQRAstoNCNxT0Eoim1aUPSgmp0/ptqV2BoXVmPzyIzEda3X3K06b18j QUJ7+yZavHpQUGdKA+hFruMM1N5ktKrsyYVMVrPqTDwq8w/JQp1vJRMmHs4/btaXttt9 xQr84qLZ6f7uJtWYOcIfXC//orc3mHjY3bCf+VGyZ0PWdmdQjQOZJI04zH/wMvqTZeFg y7YAFF+UbbMuokkx/6sSqDJDNo4yWIlKgV9ADn1acMZOPQLAATFVZrL/otw3JMbZRvZx 3PNC5oTyFyCLCSGkwWQ4BJV4GWvjQeL4qEt2Vj03So3bPE6MaKppr5d9EkMbiuwimuY7 AQlw== X-Gm-Message-State: AOAM533xMzizAZl9t2YsVGwhSd2zg5mhOXOFHir1mjPgifUNI579e11J fmEp1io3Fx1tv9RKtM1rhxByGQ== X-Google-Smtp-Source: ABdhPJwjCoHFP7Oqw3yt7wqJTgBbpS0HVBlHtxvJmr936yzXYe03jUIpN+bbTBWJs6l9J0y9TcZD1Q== X-Received: by 2002:a65:6916:: with SMTP id s22mr27610226pgq.128.1593103356458; Thu, 25 Jun 2020 09:42:36 -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 l2sm9506675pjl.34.2020.06.25.09.42.34 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 25 Jun 2020 09:42:35 -0700 (PDT) Message-ID: <3e07d41d5104466cb46e3fd076c47989fe65f085.camel@j-davis.com> Subject: Re: Default setting for enable_hashagg_disk From: Jeff Davis To: Andres Freund , Tom Lane Cc: Tomas Vondra , Justin Pryzby , Bruce Momjian , David Rowley , Robert Haas , Melanie Plageman , pgsql-hackers@postgresql.org Date: Thu, 25 Jun 2020 09:42:33 -0700 In-Reply-To: <20200624193122.cqolrvl44fh4w4s4@alap3.anarazel.de> References: <129c8f1739957589584d9525e1d8782eae3f412f.camel@j-davis.com> <20200624090628.GA19640@momjian.us> <20200624123843.GX4107@telsasoft.com> <2214502.1593019796@sss.pgh.pa.us> <20200624183203.cnqcol27ruastit7@development> <2217145.1593024050@sss.pgh.pa.us> <20200624193122.cqolrvl44fh4w4s4@alap3.anarazel.de> 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 Wed, 2020-06-24 at 12:31 -0700, Andres Freund wrote: > nodeAgg.c already treats those separately: > > void > hash_agg_set_limits(double hashentrysize, uint64 input_groups, int > used_bits, > Size *mem_limit, uint64 > *ngroups_limit, > int *num_partitions) > { > int npartitions; > Size partition_mem; > > /* if not expected to spill, use all of work_mem */ > if (input_groups * hashentrysize < work_mem * 1024L) > { > if (num_partitions != NULL) > *num_partitions = 0; > *mem_limit = work_mem * 1024L; > *ngroups_limit = *mem_limit / hashentrysize; > return; > } The reason this code exists is to decide how much of work_mem to set aside for spilling (each spill partition needs an IO buffer). The alternative would be to fix the number of partitions before processing a batch, which didn't seem ideal. Or, we could just ignore the memory required for IO buffers, like HashJoin. Granted, this is an example where an underestimate can give an advantage, but I don't think we want to extend the concept into other areas. Regards, Jeff Davis