Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t9Vmo-00Acnj-73 for pgsql-bugs@arkaria.postgresql.org; Fri, 08 Nov 2024 20:40:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1t9Vml-00DI3p-Ha for pgsql-bugs@arkaria.postgresql.org; Fri, 08 Nov 2024 20:40:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t9Vml-00DI2Z-4E for pgsql-bugs@lists.postgresql.org; Fri, 08 Nov 2024 20:40:51 +0000 Received: from mail-pl1-x62a.google.com ([2607:f8b0:4864:20::62a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1t9Vmd-000uKh-HP for pgsql-bugs@postgresql.org; Fri, 08 Nov 2024 20:40:50 +0000 Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-20ca1b6a80aso30222245ad.2 for ; Fri, 08 Nov 2024 12:40:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20230601.gappssmtp.com; s=20230601; t=1731098441; x=1731703241; darn=postgresql.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=S1Pg7bj/9h91ChnUT/+Y5MouPiyRwYleii1+BFehZcc=; b=VohIBaDJJN8E+j8bcCBWcbE9Ju+7077zqVcPXBJrxbqFJO5DOGYE1cyHk7EqP0KlKQ P5sUV7GjtsBS6RC7fY2Iwoj8cbxptsfCJQNrofIiDlu17nFhhLnlYDPI3SQttJ0hZ1tF EV3JpABQJU7jXsqJRURD0Ky6F0qyOA9gSvqgBkrRnxLJmLLabG10oW5DUYjuCffZ7zIO 3/yPQ14s7AZIfl5gMW76Uw/cS53sjJG3UGKbJvVy8VM0Wbdtutxu8aI5lxZK0hK9Xjb8 dOj78tihCkE2R2c35wEsKk5eZiZqzpS6gk/m0EC2j4CgTaQn1BRQzLcqOHYX1Uo54WnD hNtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731098441; x=1731703241; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=S1Pg7bj/9h91ChnUT/+Y5MouPiyRwYleii1+BFehZcc=; b=ANc1NYGY9mdHUzQsB9F2SHhDBj2tmUziljdek/TvVASppian7geI/fgGdZMYRO92mF gpD/2KUeft16DUbAtKm9A8Vd1bGeb6BqxL7X9+omvUnfu4/AKmsAVTKwHmvUknYa5PAe qwKk4ydnZfhtP1Fh0G/4OOfOrudqAnNG55bzzRi2mPf2mJdXm6F3nfa7FKH5QzIMT1ae 6k+X9B9gHaYSzUa69Y1wmrA71juwssruyFH1SiDNFMTstoIzdK5gtdbydntABRSk24Zo uPcEoaOteFKe+SMR7ddGUyV6wa6GD7G6vWyCyHfsWa87MM9htbHjQ0wLBW/NscI82HbG PVGg== X-Gm-Message-State: AOJu0YwZdLNOg1PrmpVyNocDTfk+PU/RxUlleqO3IYWAbCUD0wpV8BrJ P983/2ZbwU5XDd817oIvanywBloNRCm9Qwq3KX5QmS7EuinKNgj5jR7MINf4qzPnYkUuZDdopwQ = X-Google-Smtp-Source: AGHT+IFq1ZS7edV5h2KI5n3baVr3OtT5QMTu7rkyZtiu8t+rSDwO/4xGC8o4wfud8+xW7qg7u5GnTg== X-Received: by 2002:a17:902:ec8a:b0:20c:853a:52a7 with SMTP id d9443c01a7336-21183d5555dmr56576155ad.36.1731098441555; Fri, 08 Nov 2024 12:40:41 -0800 (PST) Received: from jeff-laptop.lan (c-76-102-242-158.hsd1.ca.comcast.net. [76.102.242.158]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-21177dde2d5sm34697285ad.70.2024.11.08.12.40.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Nov 2024 12:40:41 -0800 (PST) Message-ID: <8c60e698428962f33fdfbfab2206eedba09029fc.camel@j-davis.com> Subject: Re: HashAgg degenerate case From: Jeff Davis To: Andres Freund Cc: pgsql-bugs@postgresql.org Date: Fri, 08 Nov 2024 12:40:39 -0800 In-Reply-To: <33bcc1ef6c4acf80f4fb87c4d9d284c61abb3652.camel@j-davis.com> References: <4tbbgdqqxvmy37fk75p36azkovyhrjhnul46lntj52jlobphf3@nxaqlaqupg2l> <33bcc1ef6c4acf80f4fb87c4d9d284c61abb3652.camel@j-davis.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu2 MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, 2024-11-08 at 10:48 -0800, Jeff Davis wrote: > I can think of two approaches to solve it: Another thought: the point of spilling is to avoid using additional memory by adding a group. If the bucket array is 89.8% full, adding a new group doesn't require new buckets need to be allocated, so we only have the firstTuple and pergroup data to worry about. If that causes the memory limit to be exceeded, it's the perfect time to switch to spill mode. But if the bucket array is 89.9% full, then adding a new group will cause the bucket array to double. If that causes the memory limit to be exceeded, then we can switch to spill mode, but it's wasteful to do so because (a) we won't be using most of those new buckets; (b) the new buckets will crowd out space for subsequent batches and even fewer of the buckets will be used; and (c) the memory accounting can be off by quite a bit. What if we have a check where, if the metacxt is using more than 40% of the memory, and if adding a new group would reach the grow_threshold, then enter spill mode immediately? To make this work, I think we either need to use a tuplehash_lookup() followed by a tuplehash_insert() (two lookups for each new group), or we would need a new API into simplehash like tuplehash_insert_without_growing() that would return NULL instead of growing. This approach might not be backportable, but it might be a good approach for 18+. Regards, Jeff Davis