Request a Demo
Home   >   mailing lists

Re: Extended Statistics set/restore/clear functions. - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: Extended Statistics set/restore/clear functions.
Date
Msg-id CADkLM=cTVN3g7OzdSXfnBHEYNVQiGMJ8cdx1v=zJa86w1A9ULA@mail.gmail.com
Whole thread Raw
In response to Re: Extended Statistics set/restore/clear functions.  (Tomas Vondra <tomas@vondra.me>)
Responses Re: Extended Statistics set/restore/clear functions.
List pgsql-hackers
Tree view
Otherwise users may not benefit from this pg_upgrade feature for a
couple more years. Plenty of users delay upgrading until the EOL gets
close, and so might be unable to dump/restore extended stats for the
next ~5 years

Paquier's response got sidetracked because of an errant subject line change, so I will try to recap:

* pg_dump code changes no longer seem as bad on second look
* proceed with breakout per off-list discussion

in that off-list discussion I proposed (though I was mostly echoing what I thought Paquier wanted):

1. pg_ndistinct output function change.
2. pg_ndistinct input function addition.
3. pg_dependencies output function change
4. pg_dependencies input function
5. Expose attribute statistics function and rename them attstat_* or statatt_*   (edit: and fix lack of comments on the enums and arrays)
6. pg_restore_extended_stats
7. pg_dump with no ability to fetch old-format pg_ndistinct/pg_dependences. (edit: and fix inherited bug)
8. pg_dump working back as far as possible

Given that the pg_dump code no longer seems as bad, and Tomas is very much in support of it, I've opted not to split out steps 7/8.

Attachment

pgsql-hackers by date:

Previous
From: Alexander Pyhalov
Date:
Subject: Re: Asynchronous MergeAppend
Next
From: Michael Paquier
Date:
Subject: Re: [PATCH] Fix fragile walreceiver test.