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

From Hayato Kuroda (Fujitsu)
Subject RE: Statistics Import and Export
Date
Msg-id OSCPR01MB149665630030E7F54FDA8B27BF5C72@OSCPR01MB14966.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Statistics Import and Export  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Dear members,

I hope I'm in the correct thread. I found the commit 1fd1bd8 - it is so cool.
I have a question for it.

ISTM commit message said that no need to do ANALYZE again.

```
    Add support to pg_dump for dumping stats, and use that during
    pg_upgrade so that statistics are transferred during upgrade. In most
    cases this removes the need for a costly re-analyze after upgrade.
```

But pgupgrade.sgml [2] and source code [3] said that statistics must be updated.
Did I miss something, or you have been updating this?

[2]:
```
     Because optimizer statistics are not transferred by <command>pg_upgrade</command>, you will
     be instructed to run a command to regenerate that information at the end
     of the upgrade.  You might need to set connection parameters to
     match your new cluster.
```
[3]:
```
    pg_log(PG_REPORT,
           "Optimizer statistics are not transferred by pg_upgrade.\n"
           "Once you start the new server, consider running:\n"
           "    %s/vacuumdb %s--all --analyze-in-stages", new_cluster.bindir, user_specification.data);
```

Best regards,
Hayato Kuroda
FUJITSU LIMITED


pgsql-hackers by date:

Previous
From: Shlok Kyal
Date:
Subject: Re: create subscription with (origin = none, copy_data = on)
Next
From: Peter Smith
Date:
Subject: Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding