Date: Tue, 24 Aug 2021 08:13:20 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Dean Rasheed <dean.a.rasheed@gmail.com>,
	hackers <pgsql-hackers@postgresql.org>
Subject: Re: PoC/WIP: Extended statistics on expressions
Message-ID: <20210824131320.GO10479@telsasoft.com>
References: <3fbbd68b-0b52-cb5a-d468-7e7280c33e6c@enterprisedb.com>
 <4654037b-8df8-77fb-2981-67be93aebdf1@enterprisedb.com>
 <20201123022604.GD24052@telsasoft.com>
 <e5beb5d5-28b4-7aad-3a16-9a6abf57f897@enterprisedb.com>
 <6455e0ad-2a2e-bdb0-e1f8-fd4983d1c8aa@enterprisedb.com>
 <087086de-1384-8374-4efc-2e7915071d5c@enterprisedb.com>
 <CAEZATCU9uPo7JYdx4k0-ufXXZH8t7itodibUwCva+s+AvAKcnw@mail.gmail.com>
 <b2995773-c9a1-5d3b-fc90-4f3ab189be11@enterprisedb.com>
 <20210816013255.GS10479@telsasoft.com>
 <a2be7e05-e6b7-1467-d15a-49011e45a4b8@enterprisedb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a2be7e05-e6b7-1467-d15a-49011e45a4b8@enterprisedb.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20210824131320.GO10479%40telsasoft.com>
Precedence: bulk

On Mon, Aug 16, 2021 at 05:41:57PM +0200, Tomas Vondra wrote:
> > This still seems odd:
> > 
> > postgres=# CREATE STATISTICS asf ON i FROM t;
> > ERROR:  extended statistics require at least 2 columns
> > postgres=# CREATE STATISTICS asf ON (i) FROM t;
> > CREATE STATISTICS
> > 
> > It seems wrong that the command works with added parens, but builds expression
> > stats on a simple column (which is redundant with what analyze does without
> > extended stats).
> 
> Well, yeah. But I think this is a behavior that was discussed somewhere in
> this thread, and the agreement was that it's not worth the complexity, as
> this comment explains
> 
>   * XXX We do only the bare minimum to separate simple attribute and
>   * complex expressions - for example "(a)" will be treated as a complex
>   * expression. No matter how elaborate the check is, there'll always be
>   * a way around it, if the user is determined (consider e.g. "(a+0)"),
>   * so it's not worth protecting against it.
> 
> Patch 0001 fixes the "double parens" issue discussed elsewhere in this
> thread, and patch 0002 tweaks CREATE STATISTICS to treat "(a)" as a simple
> column reference.

0002 refuses to create expressional stats on a simple column reference like
(a), which I think is helps to avoid a user accidentally creating useless ext
stats objects (which are redundant with the table's column stats).

0002 does not attempt to refuse cases like (a+0), which I think is fine:
we don't try to reject useless cases if someone insists on it.
See 240971675, 701fd0bbc.

So I am +1 to apply both patches.

I added this as an Opened Item for increased visibility.

-- 
Justin