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

From Corey Huinker
Subject Re: Statistics Import and Export
Date
Msg-id CADkLM=ct-qo25r-GYO3xq8-f+ZDJCOxmC+FrwhcnFep53LnFkg@mail.gmail.com
Whole thread Raw
In response to Re: Statistics Import and Export  (Greg Sabino Mullane <htamfids@gmail.com>)
List pgsql-hackers
Attached are a couple updates that fell by the wayside and I'd like to bring focus back to them, plus one potential change, and a recap of where things stand.

0001 is a patch from Jian He [1] which removes a logic deduplication and I believe should be committed.
0002 is some attempt to cull the regression tests, eliminating extraneous parameters where possible, and reorganizing the tests

0003 is a bit more experimental.

In the interest of reducing potential ERRORs raised by pg_restore_relation_stats and pg_restore_attribute_stats within a restore or upgrade, the possibility that we attempt to restore stats to a relation that does not yet exist means that the 'foo.bar'::regclass call will fail with an ERROR. If, however, we replace the relation regclass parameter with text parameters schemaname and relname, we have the flexibility to catch this particular scenario and turn it into a WARNING instead. Likewise, if we change the attname parameter to text, we avoid those casts as well.

I'm seeking feedback on whether people think this is a positive change.

TODO

1. If the schemaname/relname change is amenable, there are some other conditions where we currently raise errors but could instead issue a WARNING instead and return false. We should settle on our preference soon-ish.

2. Commit 99f8f3fbbc8f74 introduced relallfrozen to pg_class, and pg_dump does not presently dump relallfrozen stats. I can implement this pending the feedback on schemaname/relname vs relation regclass.

3. We still have a gap in functionality in that we do not currently dump and restore extended stats. That patchset was recently updated and is covered in thread [3]. I know time is getting short, but having this at the same time would
reduce the number of customers who need to use the new vacuumdb option under development in [4], and reduce customer confusion concerning whether they are in need of post-upgrade analyzing of anything.


[1] https://www.postgresql.org/message-id/flat/CACJufxFVq%3Dtq9u1zrHWYSbMi1T07gS9Ff0LJScMco4HZmtZ1xw%40mail.gmail.com
[2] https://www.postgresql.org/message-id/flat/CAExHW5sNgxkqkyscm9KRrcwvi%2B_Hg%3DPRe_u%2BxZYJzX%2Bw4XAMjQ%40mail.gmail.com#93c77f59150be1471c38f1a315772215
Attachment

pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: Monitoring gaps in XLogWalRcvWrite() for the WAL receiver
Next
From: Andrei Lepikhov
Date:
Subject: Hook for Selectivity Estimation in Query Planning