Re: Statistics Import and Export - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Statistics Import and Export
Date
Msg-id ZzzUVrJGmtxuxSv3@nathan
Whole thread Raw
In response to Re: Statistics Import and Export  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Statistics Import and Export
List pgsql-hackers
On Mon, Nov 18, 2024 at 08:42:35PM -0500, Bruce Momjian wrote:
> We can't design an API around who is going to be surprised.  We have to
> look at what the options say, what people would expect it to do, and
> what it does.  The reason "surprise" doesn't work in the long run is
> that while PG 18 users might be surprised, PG 20 users will be confused.

I think Bruce makes good points.  I'd add that even if we did nothing at
all for vacuumdb, folks who continued to use it wouldn't benefit from the
new changes, but they also shouldn't be harmed by it, either.

>> I, personally, would be fine if this only modified --analyze-in-stages, as it
>> already carries the warning:
> 
> Right, but I think we would need to rename the option to clarify what it
> does, e.g. --analyze-missing-in-stages.  If they use
> --analyze-in-stages, they will get an error, and will then need to
> reference the docs to see the new option wording, or we can suggest the
> new option in the error message.
> 
>> But others felt that --analyze-only should be in the mix as well.
> 
> Again, with those other people not saying so in this thread, I can't
> really comment on it --- I can only tell you what I have seen and others
> are going to have to explain why they want such dramatic changes.

I don't have a strong opinion here, but I suspect that if I was creating
vacuumdb from scratch, I'd have suggested a --missing-only flag that would
only work for --analyze-only/--analyze-in-stages.  That way, folks can
still regenerate statistics if they want, but we also have an answer for
folks who use pg_upgrade and have extended statistics.

-- 
nathan



pgsql-hackers by date:

Previous
From: Michel Pelletier
Date:
Subject: Re: Using Expanded Objects other than Arrays from plpgsql
Next
From: Nathan Bossart
Date:
Subject: Re: optimize file transfer in pg_upgrade