Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d9BDx-0007V4-Bh for pgsql-hackers@arkaria.postgresql.org; Fri, 12 May 2017 14:07:17 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1d9BDw-0005ie-Ui for pgsql-hackers@arkaria.postgresql.org; Fri, 12 May 2017 14:07:16 +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_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1d9BCG-00084d-Ur for pgsql-hackers@postgresql.org; Fri, 12 May 2017 14:05:33 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1d9BCD-0000EL-Kd for pgsql-hackers@postgresql.org; Fri, 12 May 2017 14:05:32 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id v4CE5REp017301; Fri, 12 May 2017 10:05:27 -0400 From: Tom Lane To: Tomas Vondra cc: Alvaro Herrera , Simon Riggs , Andrew Dunstan , PostgreSQL-development , Dean Rasheed Subject: Re: WITH clause in CREATE STATISTICS In-reply-to: References: <20170511221330.5akgbsoyx6wm4u34@alvherre.pgsql> <22676.1494557205@sss.pgh.pa.us> Comments: In-reply-to Tomas Vondra message dated "Fri, 12 May 2017 13:13:27 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17299.1494597927.1@sss.pgh.pa.us> Date: Fri, 12 May 2017 10:05:27 -0400 Message-ID: <17300.1494597927@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Tomas Vondra writes: > On 5/12/17 4:46 AM, Tom Lane wrote: >> If people agree that that reads better, we should make an effort to >> propagate that terminology elsewhere in the docs, and into error messages, >> objectaddress.c output, etc. > I'm fine with the 'statistics object' wording. I've been struggling with > this bit while working on the patch, and I agree it sounds better and > getting it consistent is definitely worthwhile. OK. We can work on that as a followon patch. >> Although I've not done anything about it here, I'm not happy about the >> handling of dependencies for stats objects. > Yeah, it's a bit frankensteinian ... I'm prepared to create a fix for that, but it'd be easier to commit the current patch first, to avoid merge conflicts. >> Lastly, I tried the example given in the CREATE STATISTICS reference page, >> and it doesn't seem to work. > I assume you're talking about the functional dependencies and in that > case that's expected behavior, because f. dependencies do assume the > conditions are "consistent" with the functional dependencies. Hm. OK, but then that example is pretty misleading, because it leads the reader to suppose that the planner can tell the difference between the selectivities of the two queries. Maybe what's lacking is an explanation of how you'd use this statistics type. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers