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
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) |