Re: Statistics Import and Export

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Subject: Re: Statistics Import and Export
Date: 2024-03-30 11:26:59
Message-ID: CABUevEz1gLOkWSh_Vd9LQh-JM4i=Mu7PVT9ffc77TmH0Zh3TzA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Mar 30, 2024 at 1:26 AM Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
wrote:

>
>
> On Fri, Mar 29, 2024 at 7:34 PM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>
>> On Fri, 2024-03-29 at 18:02 -0400, Stephen Frost wrote:
>> > I’d certainly think “with stats” would be the preferred default of
>> > our users.
>>
>> I'm concerned there could still be paths that lead to an error. For
>> pg_restore, or when loading a SQL file, a single error isn't fatal
>> (unless -e is specified), but it still could be somewhat scary to see
>> errors during a reload.
>>
>
> To that end, I'm going to be modifying the "Optimizer statistics are not
> transferred by pg_upgrade..." message when stats _were_ transferred,
> width additional instructions that the user should treat any stats-ish
> error messages encountered as a reason to manually analyze that table. We
> should probably say something about extended stats as well.
>
>

I'm getting late into this discussion and I apologize if I've missed this
being discussed before. But.

Please don't.

That will make it *really* hard for any form of automation or drivers of
this. The information needs to go somewhere where such tools can easily
consume it, and an informational message during runtime (which is also
likely to be translated in many environments) is the exact opposite of that.

Surely we can come up with something better. Otherwise, I think all those
tools are just going ot have to end up assuming that it always failed and
proceed based on that, and that would be a shame.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ranier Vilela 2024-03-30 11:36:55 Fix out-of-bounds in the function PQescapeinternal (src/interfaces/libpq/fe-exec.c)
Previous Message Andrey M. Borodin 2024-03-30 09:11:38 Re: Various small doc improvements; plpgsql, schemas, permissions, oidvector