On 2024-Nov-27, Bruce Momjian wrote: > On Wed, Nov 27, 2024 at 02:44:01PM +0100, Magnus Hagander wrote: > > If you want to avoid both the surprise and confusion factor mentioned > > before, > > maybe what's needed is to *remove* --analyze-in-stages, and replace it with > > --analyze-missing-in-stages and --analyze-all-in-stages (with the clear > > warning > > about what --analyze-all-in-stages can do to your system if you already have > > statistics). > > > > That goes with the "immediate breakage that you see right away is better > > than > > silently doing the unexpected where you might not notice the problem until > > much > > later". > > > > That might trade some of that surprise and confusion for annoyance instead, > > but > > going forward that might be a clearer path? > > Oh, so remove --analyze-in-stages and have it issue a suggestion, and > make two versions --- yeah, that would work too.
Maybe not remove the option, but add a required parameter: --analyze-in-stages=all / missing That way, if the option is missing, the user can adapt the command line according to need. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "How amazing is that? I call it a night and come back to find that a bug has been identified and patched while I sleep." (Robert Davidson) http://archives.postgresql.org/pgsql-sql/2006-03/msg00378.php
