Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i5l74-0002zl-9L for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Sep 2019 06:19:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1i5l72-0008Qn-L8 for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Sep 2019 06:19:20 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i5l72-0008Lg-6M for pgsql-hackers@lists.postgresql.org; Thu, 05 Sep 2019 06:19:20 +0000 Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i5l6y-00058R-PT for pgsql-hackers@postgresql.org; Thu, 05 Sep 2019 06:19:19 +0000 Received: by mail-wm1-x344.google.com with SMTP id t9so1277729wmi.5 for ; Wed, 04 Sep 2019 23:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:in-reply-to:references:comments:mime-version :content-id:content-transfer-encoding:date:message-id; bh=JIOk4YJ6SLd9BksDXT0q3Kr35X/Cpcn61FIU9fiTjnA=; b=1rCN4FtnuazNAsw+lEPZ7g3DS2vgyyTS6oRnLEJSYknEvrpi+pRlvp3jEHylqXczv3 os9J+DyeRQLQnmo+eCZXQPd0Fdx9M9qq93wwmGOc/rssUAqNMpztOS9NGcqVjpvNIOeM ElZfbRDSZ1X/TnorJ56PMrAFoiHQssTR3KLdz+KeImzxnGwmX3au2+sOSs4Fv4ZaSoH8 zHINFSgZnQkt6B9cJdjjD0ICxC27s9JF77VlSQs7ZVfjVzJ602ylORbdRVNDXBBJPis7 5pnuPIRy5UohhISbPoDnlMHOstEOVFxtPWG0COa/J6g+e5CsXxpb8kmn49slevV5+o+A gA3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references :comments:mime-version:content-id:content-transfer-encoding:date :message-id; bh=JIOk4YJ6SLd9BksDXT0q3Kr35X/Cpcn61FIU9fiTjnA=; b=F2gDgDDXrDyXrLLBC1jC8VVZuJh2gJl+IEmUoWA9wWVQyBGiQrwT9745JmUldftXcE 3iPvTlKUAvHizVtqSTyOXuzyQpRWqZmaI3ZPS6dNHpIve/6LzQpXEhrP9xB78rMloBct mntFj/FSzmZn+WvWT17wSpgT8hHxDBTKnQ3o+iSeKeOzU+BaEOPbz0r2nbu/4PQMCXH1 oyu07D7T2yA7Z4B5nBmgyjE9eojBQ0iIJB8yVreQNGDl56ZmbAEjYcwsMYdTGOhFUOkd 5v/M9Vs8WelDKb9IeFLD7mI3SdqHq2NkDsyrzvxcTM7TWr9vn/BHGBbVUQs4GOtsA5zg uNRQ== X-Gm-Message-State: APjAAAV9p57S+tLkkFKyuYKYmMyu6KPILT6bJYYIrPVkvHZhyLTRSgn4 2+riB6avKCHlRUXUxf53oT/Y/jajNCE= X-Google-Smtp-Source: APXvYqwjC/qPKk3BgbcBMyXwUSbh5bG3W8Q5QqKSYC60/8wn0ZMC2jEF0y/pjqTIdgob0/cHUa0E6A== X-Received: by 2002:a1c:f20a:: with SMTP id s10mr1449475wmc.145.1567663859938; Wed, 04 Sep 2019 23:10:59 -0700 (PDT) Received: from localhost ([77.87.240.5]) by smtp.gmail.com with ESMTPSA id s1sm1243010wrg.80.2019.09.04.23.10.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Sep 2019 23:10:59 -0700 (PDT) From: Antonin Houska To: Alvaro Herrera cc: Richard Guo , Tom Lane , Michael Paquier , PostgreSQL-development Subject: Re: [HACKERS] WIP: Aggregation push-down In-reply-to: <20190904202339.GA13644@alvherre.pgsql> References: <20190904202339.GA13644@alvherre.pgsql> Comments: In-reply-to Alvaro Herrera message dated "Wed, 04 Sep 2019 16:23:39 -0400." X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.0.91 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7086.1567663857.1@localhost> Content-Transfer-Encoding: quoted-printable Date: Thu, 05 Sep 2019 08:10:58 +0200 Message-ID: <7087.1567663858@localhost> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Alvaro Herrera wrote: > This stuff seems very useful. How come it sits unreviewed for so long? I think the review is hard for people who are not interested in the planne= r very much. And as for further development, there are a few design decision= s that can hardly be resolved without Tom Lane's comments. Right now I recal= l two problems: 1) is the way I currently store RelOptInfo for the grouped relations correct?, 2) how should we handle types for which logical equali= ty does not imply physical (byte-wise) equality? Fortunately it seems now that I'm not the only one who cares about 2), so = this problem might be resolved soon: https://www.postgresql.org/message-id/CAH2-Wzn3Ee49Gmxb7V1VJ3-AC8fWn-Fr8pf= WQebHe8rYRxt5OQ%40mail.gmail.com But 1) still remains. -- = Antonin Houska Web: https://www.cybertec-postgresql.com