Re: Statistics Import and Export

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, jian he <jian(dot)universality(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, 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
Subject: Re: Statistics Import and Export
Date: 2024-11-26 22:11:42
Message-ID: CADkLM=fcAneLoFrd41zdxm_1mMZz+wTp5gLJ=Av5JtBi5cBnDQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
>
> Comments on 0003:
>
> * If we commit 0003, is it a useful feature by itself or does it
> require that we commit some or all of 0004-0014? Which of these need to
> be in v18?
>

Useful by itself.

0004 seems needed to me, unless we're fine with ~50% bloat in pg_class on a
new-upgraded system, or we think inplace update are on their way out.

0005 is basically theoretical, it is only needed if we change the default
relpages on partitioned tables.

0006-0011 are the vacuumdb things being debated now. I've reached out to
some of the people I spoke to at PgConf.eu to get them to chime in.

0012 is now moot as a similar patch was committed Friday.

0013 is a cleanup/optimization.

0014 is the --no-data flag, which has no meaning without 0004, but 0004 in
no way requires it.

>
> * Why does binary upgrade cause statistics to be dumped? Can you just
> make pg_upgrade specify the appropriate set of flags?
>

That decision goes back a ways, I tried to dig in the archives last night
but I was getting a Server Error on postgresql.org.

Today I'm coming up with
https://www.postgresql.org/message-id/267624.1711756062%40sss.pgh.pa.us
which is actually more about whether stats import should be the default
(consensus: yesyesyes), and the binary_upgrade test may have been because
binary_upgrade shuts off data section stuff, but table stats are in the
data section. Happy to review the decision.

> * It looks like appendNamedArgument() is never called with
> positional=true?
>

That is currently the case. Currently all params are called with name/value
pairs, but in the past we had leading positionals followed by the stat-y
parameters in name-value pairs. I'll be refactoring it to remove the
positonal=T/F argument, which leaves just a list of name-type pairs, and
thus probably reduces the urge to make it an array of structs.

> * It's pretty awkward to use an array of arrays of strings when an
> array of structs might make more sense.

That pattern was introduced here:
https://www.postgresql.org/message-id/4afa70edab849ff16238d1100b6652404e9a4d9d.camel%40j-davis.com
:)

I'll be rebasing (that's done) and refactoring 0003 to get rid of the
positional column, and moving 0014 next to 0003 because they touch the same
files.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alec Larson 2024-11-26 22:43:05 Proposal: Support for "NOT NULL" Constraints on Composite Type Fields (Checked at Rest)
Previous Message Tomas Vondra 2024-11-26 22:07:12 Re: Changing the state of data checksums in a running cluster