From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
---|---|
To: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Davis <pgsql(at)j-davis(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>, Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, alvherre(at)alvh(dot)no-ip(dot)org, jian he <jian(dot)universality(at)gmail(dot)com> |
Subject: | Re: Statistics Import and Export |
Date: | 2025-03-05 08:08:55 |
Message-ID: | CADkLM=ct-qo25r-GYO3xq8-f+ZDJCOxmC+FrwhcnFep53LnFkg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
[3]
https://www.postgresql.org/message-id/flat/CADkLM%3DdnFKZMAo7MwqD2X6JjiiLCoVXHmszqtZp8sycYmoCcMQ%40mail.gmail.com#eff41d39f7158086e8398803165c5c2f
[4]
https://www.postgresql.org/message-id/flat/CANWCAZZf_jNn2i%2B6-JfQt_j909DBk-U6Dg0M7iArZPLgdXCAmw%40mail.gmail.com#e575b5bede51455f406ac3872d2f82ec
Attachment | Content-Type | Size |
---|---|---|
v5-0001-refactor-_tocEntryRequired-for-STATISTICS-DATA.patch | text/x-patch | 2.1 KB |
v5-0002-Organize-and-deduplicate-statistics-import-tests.patch | text/x-patch | 92.7 KB |
v5-0003-Split-relation-into-schemaname-and-relname.patch | text/x-patch | 62.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrei Lepikhov | 2025-03-05 08:41:42 | Hook for Selectivity Estimation in Query Planning |
Previous Message | Bertrand Drouvot | 2025-03-05 08:04:44 | Re: Monitoring gaps in XLogWalRcvWrite() for the WAL receiver |