Re: Additional improvements to extended statistics

On Sun, Mar 15, 2020 at 02:48:02PM +1300, Thomas Munro wrote:
>On Sun, Mar 15, 2020 at 1:08 PM Tomas Vondra
><tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>> On Sat, Mar 14, 2020 at 05:56:10PM +0100, Tomas Vondra wrote:
>> >Attached is a patch series rebased on top of the current master, after
>> >committing the ScalarArrayOpExpr enhancements. I've updated the OR patch
>> >to get rid of the code duplication, and barring objections I'll get it
>> >committed shortly together with the two parts improving test coverage.
>> >
>>
>> I've pushed the two patches improving test coverage for functional
>> dependencies and MCV lists, which seems mostly non-controversial. I'll
>> wait a bit more with the two patches actually changing behavior (rebased
>> version attached, to keep cputube happy).
>
>Some comment fixes:
>
>- /* Check if the expression the right shape (one Var,
>one Const) */
>- if (!examine_clause_args(expr->args, &var, NULL, NULL))
>+ /*
>+ * Check if the expression the right shape (one Var
>and one Const,
>+ * or two Vars).
>+ */
>
>Check if the expression "has" or "is of" the right shape.
>
>- * Attempts to match the arguments to either (Var op Const) or (Const op Var),
>- * possibly with a RelabelType on top. When the expression matches this form,
>- * returns true, otherwise returns false.
>+ * Attempts to match the arguments to either (Var op Const) or (Const op Var)
>+ * or (Var op Var), possibly with a RelabelType on top. When the expression
>+ * matches this form, returns true, otherwise returns false.
>
>... match the arguments to (Var op Const), (Const op Var) or (Var op Var), ...
>
>+ /*
>+ * Both variables have to be for the same relation
>(otherwise it's
>+ * a join clause, and we don't deal with those yet.
>+ */
>
>Missing close parenthesis.
>

Thanks, I'll get this fixed.

>Stimulated by some bad plans involving JSON, I found my way to your
>WIP stats-on-expressions patch in this thread. Do I understand
>correctly that it will eventually also support single expressions,
>like CREATE STATISTICS t_distinct_abc (ndistinct) ON
>(my_jsonb_column->>'abc') FROM t? It looks like that would solve
>problems that otherwise require a generated column or an expression
>index just to get ndistinct.

Yes, I think that's generally the plan. I was also thinking about
inventing some sort of special JSON statistics (e.g. extracting paths
from the JSONB and computing frequencies, or something like that). But
stats on expressions are one of the things I'd like to do in PG14.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services