Re: extended stats not friendly towards ANALYZE with subset of columns

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Subject: Re: extended stats not friendly towards ANALYZE with subset of columns
Date: 2017-04-17 17:12:23
Message-ID: 20170417171223.byb4ucocrup3pwl5@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Rowley wrote:

> ERROR: extended statistics could not be collected for column "a" of
> relation public.ab1
> HINT: Consider ALTER TABLE "public"."ab1" ALTER "a" SET STATISTICS -1
>
> I don't think the error is useful here, as it means nothing gets done.
> Probably better to just not (re)build those stats.

Agreed, an error there is a bad idea.

> Another option would be to check for extended stats before deciding
> which rows to ANALYZE, then still gathering the columns required for
> MV stats, but I think if the user asks for a subset of columns to be
> analyzed, and that causes a column to be missing for an extended
> statistics, that it would be pretty surprising if we rebuild the
> extended stats.

That would be very surprising indeed.

> Perhaps the SET STATISTIC 0 for a column still needs to gather data
> for extended statistics, though. Perhaps a debate should ensue about
> how that should work exactly.

Hmm. I'd rather throw a warning at either CREATE STATISTICS time or at
ALTER TABLE SET STATISTICS time, rather than magically changing the set
of columns at analyze time.

> I've attached a patch which fixes the problem above, but it does
> nothing to change the analyze behaviour for 0 statistics columns.

Pushed, after tweaking so that a WARNING is still emitted, because it's
likely to be useful in pointing out a procedural mistake while extended
stats are being tested.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-04-17 17:14:12 Re: Cutting initdb's runtime (Perl question embedded)
Previous Message Tom Lane 2017-04-17 17:09:33 Re: Cutting initdb's runtime (Perl question embedded)