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 1stLvg-00FY1N-7J for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Sep 2024 06:55:16 +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 1stLvf-004PKh-K7 for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Sep 2024 06:55:15 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1stLvf-004PK5-Ai for pgsql-hackers@lists.postgresql.org; Wed, 25 Sep 2024 06:55:15 +0000 Received: from mail-yw1-x1134.google.com ([2607:f8b0:4864:20::1134]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1stLvc-000wn9-HD for pgsql-hackers@postgresql.org; Wed, 25 Sep 2024 06:55:14 +0000 Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-6dddca05a60so6232697b3.0 for ; Tue, 24 Sep 2024 23:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727247312; x=1727852112; darn=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=+AFxxMjjxk7gHe0t/pPaFLHtTxKhVe1aFiZAAi6uHj0=; b=JlAo5Zux4egW7pMiPixTzi8z5qHV32Mkk6bbdQkRAOVlZaTo0BkUzWGChxbLUAL6sH TGG3vdXAEt41uyU5/GViRfL0g70dfzeeHDZzw9EgOF9r0fvFc3hSTSPDKWYT11l5RznU zD89ItwZMDRKeGwzVYdUNu4XNiBQ1zlib5LJxX5f+phDvbsY4bJrByv25ZoPnL2MXnOG klwkchOn5XXcX4m3KmZMazFHgHtGApuYYBE/Or0ZKP1B0B6oQ7qHFFhgjBa9ro/s6b7D xR/snxeO+bJnLvOHzWsBacAboYg/ynN1GpfdJ9lQlU95l3TufyBx+63pqGsi2ADhfjbV Mjdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727247312; x=1727852112; 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=+AFxxMjjxk7gHe0t/pPaFLHtTxKhVe1aFiZAAi6uHj0=; b=w76dX3rPg6ZsE3HSF1ucjB03Ql0AtlqN1FZ6Dck5ssYAXP/vQ3hJt7ichNW2NX8P6Y mMf0fZ69Zk065EW+HMF7qJVA8YbqTbSwi0fsk6wNPPQwCIZONtkWre9kK8kW9x5wOPSk W3Q6h4rtciIwUZ2iCKIFRT54GOZrHvqkxFDAzJrr9vyfuSK0CRIbjHXB4RG+zHokdXLG TCPIEJDRUySLcAMNwM3e1vvAH46zSh/YDTt0buRZa1OsC2sAlEALLO6EY7zE6zaGewn6 0Ot7EpPrs06dIWCDvGwqmMCKqLPjRcHRxp7nUACfJ+zo6T8ECGMMqSPSwPl29tK7o4++ Pl8g== X-Forwarded-Encrypted: i=1; AJvYcCVGSCZTB8TmE4RYP8Uw9RMhZybGCE5Yg1qe9V8W/TLCy2GRB4EDJDx/AFPEm5oP0IA6GmYYZ0Snaee7pbaj@postgresql.org X-Gm-Message-State: AOJu0Yy/zZFPjKaQkMBHsy7RJZ9qYDg7M2ViWatUvdUsz5FN512x8iH4 q52bBq2n4VcCmx7oXk1RBldU+kRhJiPTrBAkB6dOjRZ+ESyvW7JZZ1GNUUz0cpUeNJeaLT4Cyvg TwrGOWn7zZDKhKxxhJDLuifxC638= X-Google-Smtp-Source: AGHT+IGDVYhnntBH+Nkhv8u9/o321BxoueK+XrZyF+IEv+bj4S/AY/QLCHoLV6fCI/MYeC5UNkh4lM0Gf9a3t+m7xvU= X-Received: by 2002:a05:690c:399:b0:6db:e069:b76f with SMTP id 00721157ae682-6e21e32f47cmr11331457b3.9.1727247311843; Tue, 24 Sep 2024 23:55:11 -0700 (PDT) MIME-Version: 1.0 References: <87il22cj51.fsf@163.com> In-Reply-To: From: Richard Guo Date: Wed, 25 Sep 2024 14:55:00 +0800 Message-ID: Subject: Re: Eager aggregation, take 3 To: Tender Wang Cc: Paul George , Andy Fan , PostgreSQL-development , pgsql-hackers@lists.postgresql.org, Robert Haas 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 Thu, Sep 5, 2024 at 9:40=E2=80=AFAM Tender Wang wro= te: > 1. in setup_eager_aggregation(), before calling create_agg_clause_infos(= ), it does > some checks if eager aggregation is available. Can we move those checks i= nto a function, > for example, can_eager_agg(), like can_partial_agg() does? We can do this, but I'm not sure this would be better. > 2. I found that outside of joinrel.c we all use IS_DUMMY_REL, but in jo= inrel.c, Tom always uses > is_dummy_rel(). Other commiters use IS_DUMMY_REL. They are essentially the same: IS_DUMMY_REL() is a macro that wraps is_dummy_rel(). I think they are interchangeable, and I don=E2=80=99t have= a preference for which one is better. > 3. The attached patch does not consider FDW when creating a path for gro= uped_rel or grouped_join. > Do we need to think about FDW? We may add support for foreign relations in the future, but for now, I think we'd better not expand the scope too much until we ensure that everything is working correctly. Thanks Richard