Re: Statistics Import and Export
| От | Magnus Hagander |
|---|---|
| Тема | Re: Statistics Import and Export |
| Дата | |
| Msg-id | CABUevEzo_gz4o0W-grWdZvxP-hHRfgzJB8DPAy4GyvTUoWBCDg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Statistics Import and Export (Bruce Momjian <bruce@momjian.us>) |
| Ответы |
Re: Statistics Import and Export
|
| Список | pgsql-hackers |
On Tue, Nov 19, 2024 at 1:50 PM Bruce Momjian <bruce@momjian.us> wrote:
On Mon, Nov 18, 2024 at 08:42:35PM -0500, Bruce Momjian wrote:
> On Mon, Nov 18, 2024 at 08:29:10PM -0500, Corey Huinker wrote:
> > That's not a great surprise for group 6, but I have to believe that group is
> > smaller than group 5, and it's definitely smaller than the group of users that
> > need to upgrade.
>
> Again, a clean API is the goal, not surprise calculus.
Maybe I was too harsh. "Surprise calculus" is fine, but only after we
have an API that will be clearly understood by new users. We have to
assume that in the long run new users will use this API more than
existing users.
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?
В списке pgsql-hackers по дате отправления: