Horton

Re: Statistics Import and Export

Corey Huinker <corey.huinker@gmail.com>

View thread
From: Corey Huinker <corey.huinker@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: jian he <jian.universality@gmail.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>, Bruce Momjian <bruce@momjian.us>, Tom Lane <tgl@sss.pgh.pa.us>, Nathan Bossart <nathandbossart@gmail.com>, Magnus Hagander <magnus@hagander.net>, Stephen Frost <sfrost@snowman.net>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Peter Smith <smithpb2250@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, alvherre@alvh.no-ip.org
Date: 2024-11-08T18:25:21Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Change pg_dump default for statistics export.

  2. pg_dump: Adjust reltuples from 0 to -1 for dumps of older versions.

  3. vacuumdb: Don't skip empty relations in --missing-stats-only mode.

  4. pg_dump: Fix query for gathering attribute stats on older versions.

  5. Prevent redeclaration of typedef TocEntry.

  6. Remove unused function parameters in pg_backup_archiver.c.

  7. pg_dump: Retrieve attribute statistics in batches.

  8. pg_dump: Reduce memory usage of dumps with statistics.

  9. Skip second WriteToc() call for custom-format dumps without data.

  10. Add relallfrozen to pg_dump statistics.

  11. Matview statistics depend on matview data.

  12. Add pg_dump --with-{schema|data|statistics} options.

  13. Stats: use schemaname/relname instead of regclass.

  14. CREATE INDEX: do update index stats if autovacuum=off.

  15. Don't convert to and from floats in pg_dump.

  16. CREATE INDEX: don't update table stats if autovacuum=off.

  17. Organize and deduplicate statistics import tests.

  18. Address stats export review comments.

  19. Address stats import review comments.

  20. Add relallfrozen to pg_class

  21. Fix pg_strtof() to not crash on NULL endptr.

  22. Use attnum to identify index columns in pg_restore_attribute_stats().

  23. pg_dump: prepare attribute stats query.

  24. Avoid unnecessary relation stats query in pg_dump.

  25. Remove redundant pg_set_*_stats() variants.

  26. Do not use in-place updates for statistics import.

  27. Fix confusion about data type of pg_class.relpages and relallvisible.

  28. Documentation fixups for dumping statistics.

  29. Trial fix for old cross-version upgrades.

  30. Transfer statistics during pg_upgrade.

  31. Lock table in ShareUpdateExclusive when importing index stats.

  32. Use in-place updates for pg_restore_relation_stats().

  33. Improve error message for replication of generated columns.

  34. pg_dump: Add dumpSchema and dumpData derivative flags.

  35. Disallow modifying statistics on system columns.

  36. Add missing CommandCounterIncrement() in stats import functions.

  37. Add functions pg_restore_relation_stats(), pg_restore_attribute_stats().

  38. Documentation fixup.

  39. Add functions pg_set_attribute_stats() and pg_clear_attribute_stats().

  40. Change pg_*_relation_stats() functions to return type to void.

  41. Disable autovacuum for tables in stats import tests.

  42. Allow pg_set_relation_stats() to set relpages to -1.

  43. Fixup for pg_set_relation_stats().

  44. Create functions pg_set_relation_stats, pg_clear_relation_stats.

  45. Add memory/disk usage for Window aggregate nodes in EXPLAIN.

  46. Improve performance of dumpSequenceData().

  47. Add INJECTION_POINT_CACHED() to run injection points directly from cache

  48. Improve performance of binary_upgrade_set_pg_class_oids().

  49. Improve assertion in mdwritev()

  50. CREATE INDEX: do not update stats during binary upgrade.

  51. Redefine pg_class.reltuples to be -1 before the first VACUUM or ANALYZE.

Attachments

>
> WHAT IS NOT DONE - EXTENDED STATISTICS
>
> It is a general consensus in the community that "nobody uses extended
> statistics", though I've had difficulty getting actual figures to back this
> up, even from my own employer. Surveying several vendors at PgConf.EU, the
> highest estimate was that at most 1% of their customers used extended
> statistics, though more probably should. This reinforces my belief that a
> feature that would eliminate a major pain point in upgrades for 99% of
> customers shouldn't be held back by the fact that the other 1% only have a
> reduced hassle.
>
> However, having relation and attribute statistics carry over on major
> version upgrades presents a slight problem: running vacuumdb
> --analyze-in-stages after such an upgrade is completely unnecessary for
> those without extended statistics, and would actually result in _worse_
> statistics for the database until the last stage is complete. Granted,
> we've had great difficulty getting users to know that vacuumdb is a thing
> that should be run, but word has slowly spread through our own
> documentation and those "This one simple trick will make your postgres go
> fast post-upgrade" blog posts. Those posts will continue to lurk in search
> results long after this feature goes into release, and it would be a rude
> surprise to users to find out that the extra work they put in to learn
> about a feature that helped their upgrade in 17 was suddenly detrimental
> (albeit temporarily) in 18. We should never punish people for only being a
> little-bit current in their knowledge. Moreover, this surprise would
> persist even after we add extended statistics import function functionality.
>
> I presented this problem to several people at PgConf.EU, and the consensus
> least-bad solution was that vacuumdb should filter out tables that are not
> missing any statistics when using options --analyze, --analyze-only, and
> --analyze-in-stages, with an additional flag for now called --force-analyze
> to restore the un-filtered functionality. This gives the outcome tree:
>
> 1. Users who do not have extended statistics and do not use (or not even
> know about) vacuumdb will be blissfully unaware, and will get better
> post-upgrade performance.
> 2. Users who do not have extended statistics but use vacuumdb
> --analyze-in-stages will be pleasantly surprised that the vacuumdb run is
> almost a no-op, and completes quickly. Those who are surprised by this and
> re-run vacuumdb --analyze-in-stages will get another no-op.
> 3. Users who have extended statistics and use vacuumdb --analyze-in-stages
> will get a quicker vacuumdb run, as only the tables with extended stats
> will pass the filter. Subsequent re-runs of vacuumdb --analyze-in-stages
> would be the no-op.
> 4. Users who have extended statistics and don't use vacuumdb will still
> get better performance than they would have without any stats imported.
>
> In case anyone is curious, I'm defining "missing stats" as a table/matview
> with any of the following:
>
> 1. A table with an attribute that lacks a corresponding pg_statistic row.
> 2. A table with an index with an expression attribute that lacks a
> corresponding pg_statistic row (non-expression attributes just borrow the
> pg_statistic row from the table's attribute).
> 3. A table with at least one extended statistic that does not have a
> corresponding pg_statistic_ext_data row.
>
> Note that none of these criteria are concerned with the substance of the
> statistics (ex. pg_statistic row should have mcv stats but does not),
> merely their row-existence.
>
> Some rejected alternative solutions were:
>
> 1. Adding a new option --analyze-missing-stats. While simple, few people
> would learn about it, knowledge of it would be drowned out by the
> aforementioned sea of existing blog posts.
> 2. Adding --analyze-missing-stats and making --analyze-in-stages fail with
> an error message educating the user about --analyze-missing-stats. Users
> might not see the error, existing tooling wouldn't be able to act on the
> error, and there are legitimate non-upgrade uses of --analyze-in-stages.
>
> MAIN CONCERN GOING FORWARD
>
> This change to vacuumdb will require some reworking of the
> vacuum_one_database() function so that the list of tables analyzed is
> preserved across the stages, as subsequent stages runs won't be able to
> detect which tables were previously missing stats.
>
>

Here's a rebased patchset, with the changes to vacuum broken down into baby
steps to make things easier on a reviewer.

0001-0005 same as before, rebased.
0006-0009 structural changes to vacuumdb to make the new feature simpler.
0010 add test issues_sql_unlike, this was needed because we didn't have a
way to determine that a given line _wasn't_ printed.
0011 add --force-analyze to vacuumdb and filter out tables with existing
statistics otherwise.