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.
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 |