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 1ux8pX-00BFas-US for pgsql-hackers@arkaria.postgresql.org; Fri, 12 Sep 2025 18:49:08 +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 1ux8oW-003RIy-0F for pgsql-hackers@arkaria.postgresql.org; Fri, 12 Sep 2025 18:48:04 +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 1ux8oV-003RIq-Mf for pgsql-hackers@lists.postgresql.org; Fri, 12 Sep 2025 18:48:04 +0000 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1ux8oS-000Swn-18 for pgsql-hackers@lists.postgresql.org; Fri, 12 Sep 2025 18:48:04 +0000 Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-62ec693c618so3312475a12.1 for ; Fri, 12 Sep 2025 11:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757702881; x=1758307681; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=LCXrzWomZ2ZHu6cBnflOKg60/4V2YZJPGN0Vl9+rqSQ=; b=gGvILVnP65lV+SS+V7IwXSQ+XRYNlUavcZeXdsUljYFj4LR3gxMkRua6YikIKKTT+n fak4PsNBymegVMNLZY2G5uiishxk8QHU2+qyRpVTpai4hzF7lYCJj2QYuS/Mweyy2KM7 2+8vFdv+KJEi7X47cfI6aap0TCQqvljgnbRht9beRUarkplaY2OeFjTTsipVkPcpOiVM 0/QY3jX7dYP7uFf6W5TU6zzQTuMjJddaxRfYyfbGSWgkQyO+PXr9neqwZrjYTYxHegEE 6NHA2GFcKi0dKeWMv5QIOCavnCr0qOAwcxyg4LbnjZe4riQ6HEUseMiY/BA4eP5w0eK+ mF5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757702881; x=1758307681; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LCXrzWomZ2ZHu6cBnflOKg60/4V2YZJPGN0Vl9+rqSQ=; b=xHdiP7k+wz/yxeq7slZdzaaGDnHdMAm3QwBbPWzRizzbI2FttpoWc1kJY/MnHiaP8t c4A023C9MFteYU01DP/W91xwzFbKN9q2gTGy1VReiCBSV6W0Y5/wQEwG5oVu8Aq/QXcm 7ywpYyWSlkaxwW/q5ogjRm5Pfsrv4Wlayt3AwVB8J8hwV3R1LC+9rAilzjwQAKaBDQl4 FWNf9IBBx0LIEY9722jWokA3077GNMjliNVyXPlY4rPtMLw6P2ubgJw/MeD1A4QzS5Ov xF1rCjuKsHUwdAXTbOXZThkSLSGY5Jj/OJqyU1zdDSNtPvj9mfXJBd/iXxDExz0bHN9u r55w== X-Forwarded-Encrypted: i=1; AJvYcCWKjP9JyKDq5Tk7iaAJF76jv81dcJ6jGSs8iZ5w70E2CaZieqwis1CoSSs2gOcpngqMs6m7JwrMarZ7+Ho/@lists.postgresql.org X-Gm-Message-State: AOJu0YxRJhqtB7IBoZux/Xc+lLI2PiMM4v30p6JezyVt4e6eIb1oX6C7 rdOHn2KeysiBKG7D3sf9C/BBd/Ye4xvi3M7WlbhHT0hrGw82kFdlbtC/fMjkoNpKoQHj4IAP6y/ o9x2yxAPwiG7w1la8aWLeV4XSGRDGcfk= X-Gm-Gg: ASbGncvEKOt24vdQywByJAmGr9O2felZTdfc3AhMie9V2GlqK3ggL6ABbnJDU11e/ZA mMvtRAKPjxk49sx8iFMeBCOOvBo34m2VvbaUaPySYKWntZr7maxkxqIK3RU4QLiBfFehIL/t6E/ VoenWT+3iAONcTj5KSG8p9HJAEgghKkUr4uuXeZTcY2sUanBum8UmjKX/x5DTmAsMeTe7tJyN0S 0xbj/Hgog== X-Google-Smtp-Source: AGHT+IFabxocnStLZNS5V8E42mUJW6idG9DfVzaL9Co1ja00EdeUO1YsR1Opf00adBFqNfj8RvujOQhC7kr+jutzI58= X-Received: by 2002:a17:907:970f:b0:b04:7708:ee36 with SMTP id a640c23a62f3a-b07c3540964mr351772666b.9.1757702880764; Fri, 12 Sep 2025 11:48:00 -0700 (PDT) MIME-Version: 1.0 References: <87il22cj51.fsf@163.com> In-Reply-To: From: Robert Haas Date: Fri, 12 Sep 2025 14:47:48 -0400 X-Gm-Features: Ac12FXwsP-_eCw97fME4437jGKSz0IALq2EX8eIM44izIfN7PYHKZwZxQIIypA0 Message-ID: Subject: Re: Eager aggregation, take 3 To: Richard Guo Cc: Tom Lane , Tender Wang , Paul George , Andy Fan , PostgreSQL-development , pgsql-hackers@lists.postgresql.org, Matheus Alcantara Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Sep 12, 2025 at 5:34=E2=80=AFAM Richard Guo wrote: > I really like this idea. Currently, aggtransspace represents an > estimate of the transition state size provided by the aggregate > definition. If it's set to zero, a default estimate based on the > state data type is used. Negative values currently have no defined > meaning. I think it makes perfect sense to reuse this field so that > a negative value indicates that the transition state data can grow > unboundedly in size. > > Attached 0002 implements this idea. It requires fewer code changes > than I expected. This is mainly because that our current code uses > aggtransspace in such a way that if it's a positive value, that value > is used as it's provided by the aggregate definition; otherwise, some > heuristics are applied to estimate the size. For the aggregates that > accumulate input rows (e.g., array_agg, string_agg), I don't currently > have a better heuristic for estimating their size, so I've chosen to > keep the current logic. This won't regress anything in estimating > transition state data size. This might be OK, but it's not what I was suggesting: I was suggesting trying to do a calculation like space_used =3D -aggtransspace * rowcount, not just using a <0 value as a sentinel. --=20 Robert Haas EDB: http://www.enterprisedb.com