On Mon, Mar 31, 2025 at 1:10 AM Corey Huinker
wrote:
> Just rebasing.
>
At pgconf.dev this year, the subject of changing the formats of
pg_ndistinct and pg_depdentencies came up again.
To recap: presently these datatypes have no working input function, but
would need one for statistics
>
> I don't know precisely where that line might be, but in this case, the
> dumped stats have no hope of restoring into anything older than v18 (since
> the stats import functions won't exist), which is well past the point where
> we started using -1 for reltuples. If we could dump the stats from
>
> > I've had this idea before, and even wrote a quick POC at one point, but
> I had it simply throw a warning rather than an
> > error. That avoids the need for any GUC, which I agree is not a good
> idea. And it still allows people to create a
> > duplicate index if they really want to.
> >
>
>
>
> You might be getting confused because the code does look at the
> pg_class fields, but that's only to estimate the tuple density. When
> pg_class has those estimates, they're used to calculate the estimated
> density by doing reltuples / relpages, but that average rows per page
>
>
Thanks for t
>
> The whole thing might take about 20 to 30 hours wall-clock time.
>
After this dev cycle, things with a defined end to them hold a greater
attraction than they did previously.
> So, there is some time to think about this. Please discuss here if
> you're interested or have questions.
>
I am
>
> * Question
>
> By using Statistics Import and Export feature, is it possible to achieve
> the above request by following procedure?
>
>
>
> (1) Export the statistics from production environment by using pg_dump
> --statistics-only.
>
> (2) On the staging environment, set the autovacuum related
>
> at the *actual size* of the relation and takes that into account when
> scaling the statistics (see table_block_relation_estimate_size() in
> tableam.c). If the table sizes don't match between the two servers
> then there's no guarantees the planner will produce the same plan.
>
Sorry that I d
>
> * Changed to use LookupExplicitNamespace()
>
Seems good.
> * Added test for temp tables
>
+1
> * Doc fixes
So this patch swings the pendulum a bit back towards accepting some things
as errors. That's understandable, as we're never going to have a situation
where we can guarantee that th
>
> > Also, why do we need the clause "WHERE s.tablename = ANY($2)"? Isn't
> > that already implied by "JOIN unnest($1, $2) ... s.tablename =
> > u.tablename"?
>
> Good question. Corey, do you recall why this was needed?
>
In my patch, that SQL statement came with the comment:
+ /*
+ * The resul
>
> The first is that i_relallfrozen is undefined in versions earlier than
> 18. That's trivial to fix, we just add "0 AS relallfrozen," in the
> earlier versions, but still refrain from outputting it.
>
Ok, so long as we refrain from outputting it, I'm cool with whatever we
store internally.
>
until v9.4. Looking into it...
>
>
>
This patch shrinks the array size to 1 for versions < 9.4, which keeps the
modern code fairly elegant.
From fe551ab55622f95d84ac4c4d79fba898c6b60057 Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Fri, 4 Apr 2025 19:30:00 -0400
Subject: [PATC
>
> I'm hesitating about the right syntax, though, for an input backslash
> command which in effect would really only apply to COPY? ISTM that \g* is
> used for "go", i.e. a semi-colon replacement which executes the SQL, and we
> should want the same thing, which suggests:
>
making it a \g-variant
>
> Anyway, my feeling about it is that \copy parsing is a huge hack
> right now, and I'd rather see it become less of a hack, that is
> more like other psql commands, instead of getting even hackier.
>
I wasn't as horrified as Tom, but it did have the feeling of it solving
half the problem.
We c
ing step in
>> adjust_new_dumpfile?
>>
>
> That sounds trickier.
>
Narrator: It was not trickier.
In light of v11-0001 being committed as 4694aedf63bf, I've rebased the
remaining patches.
From 607984bdcc91fa31fb7a12e9b24fb8704aa14975 Mon Sep 17 00:00:00 2001
From: Corey Huinke
A rebase and a reordering of the commits to put the really-really-must-have
relallfrozen ahead of the really-must-have stats batching and both of them
head of the error->warning step-downs.
From 96b10b1eb955c5619d23cadf7de8b12d2db638a9 Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Sat,
And here's the rebase (after bde2fb797aaebcbe06bf60f330ba5a068f17dda7).
The order of the patches is different, but the purpose of each is the same
as before.
From 1f9b2578f55fa1233121bcf5949a6f69d6cf8cee Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Fri, 14 Mar 2025 03:54:26 -0400
Subject: [PATCH v1
>
> The original reason we wanted to issue warnings was to allow ourselves
> a chance to change the meaning of parameters, add new parameters, or
> even remove parameters without causing restore failures. If there are
> any ERRORs that might limit our flexibility I think we should downgrade
> those
>
> This replaces regclassin with custom lookups of the namespace and
> relname, but misses some of the complexities that regclassin is
> handling. For instance, it calls RangeVarGetRelid(), which calls
> LookupExplicitNamespace(), which handles temp tables and
> InvokeNamespaceSearchHook().
>
> At
>
>
> While preparing this for commit, I noticed that the expression index part
> of the query was disregarding attstattarget. To fix, I've modified that
> part to look at the index's pg_attribute entries.
>
+1, should have been there all along.
On Mon, Mar 17, 2025 at 10:24 AM Nathan Bossart
wrote:
> On Sun, Mar 16, 2025 at 05:32:15PM -0400, Corey Huinker wrote:
> >>
> >> * The custom format actually does two WriteToc() calls, and since these
> >> patches move the queries to this part of pg_dump, it me
>
> * The custom format actually does two WriteToc() calls, and since these
> patches move the queries to this part of pg_dump, it means we'll run all
> the queries twice. The comments around this code suggest that the second
> pass isn't strictly necessary and that it is really only useful
On Thu, Mar 6, 2025 at 3:48 AM Jeff Davis wrote:
> On Wed, 2025-03-05 at 23:04 -0500, Corey Huinker wrote:
> >
> > Anyway, here's a rebased set of the existing up-for-consideration
> > patches, plus the optimization of avoiding querying on non-expression
> &g
>
>
> https://www.postgresql.org/docs/current/ddl-priv.html
>
> The above text indicates that we should do the check, but also that
> it's not terribly important for actual security.
>
Ok, I'm convinced.
>
> > If we do, we'll want to change downgrade the following errors to
> > warn+return fals
>
> I don't follow. We already have the tablenames, schemanames and oids of the
> to-be-dumped tables/indexes collected in pg_dump, all that's needed is to
> send
> a list of those to the server to filter there?
>
Do we have something that currently does that? All of the collect functions
(collect
>
> Until we add a fourth option, and then it becomes completely ambiguous as
>> to whether you wanted data+statstics, or you not-wanted schema.
>>
>>
> except it is perfectly clear that you *asked for* data and statistics, so
> you get what you asked for. however the user conjures in their heads w
a couple
orders of magnitude gain.
From 9cd4b4e0e280d0fd8cb120ac105d6e65a491cd7e Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Tue, 4 Mar 2025 22:16:52 -0500
Subject: [PATCH v7 1/2] Split relation into schemaname and relname.
In order to further reduce potential error-failures in restor
On Sat, Mar 8, 2025 at 12:52 AM Hari Krishna Sunder
wrote:
> To improve the performance of pg_dump can we add a new sql function that
> can operate more efficiently than the pg_stats view? It could also take in
> an optional list of oids to filter on.
> This will help speed up the dump and restor
>
> I tried to generalize that requirement to all of
> {schema|data|statistics} for consistency, but that resulted in 9
> options.
>
9 options that resolve to 3 boolean variables. It's not that hard.
And if we add a fourth option set, then we have 12 options. So it's O(3N),
not O(N^2).
People ha
>
>
> if you want everything --include=schema,data,statistics (presumably
> redundant with the default behavior)
> if you want schema only --include=schema
> if you want "everything except schema" --include=data,statistics
>
Until we add a fourth option, and then it becomes completely ambiguous as
>
>
> Patch attached. This patch does NOT change the default; stats are still
> opt-out. But it makes it easier for users to start specifying what they
> want or not explicitly, or to rely on the defaults if they prefer.
>
> Note that the patch would mean we go from 2 options in v17:
> --{schema|
>
> To be honest, I am a bit surprised that we decided to enable this by
> default. It's not obvious to me that statistics should be regarded as
> part of the database in the same way that table definitions or table
> data are. That said, I'm not overwhelmingly opposed to that choice.
> However, ev
>
>
> The more I think about it, the less correct it seems to me to have the
> statement to restore statistics tracked via ArchiveOpts->createStmt. We
> use
> that for DDL, but this really is data, not DDL. Because we store it in
> ->createStmt it's stored in-memory for the runtime of pg_dump, wh
>
> Would it be appropriate to create a temp table? I wouldn't normally
> expect pg_dump to create temp tables, but I can't think of a major
> reason not to.
>
I think we can't - the db might be a replica.
>
> If not, did you have in mind a CTE with a large VALUES expression, or
> just a giant I
>
>
>
> > Pardon my inexperience, but aren't the ArchiveEntry records needed right
> up
> > until the program's run?
>
> s/the/the end of the/?
>
yes
> > If there's value in freeing them, why isn't it being done already? What
> > other thing would consume this freed memory?
>
> I'm not saying th
On Wed, Mar 5, 2025 at 9:18 PM Andres Freund wrote:
> Hi,
>
> On 2025-03-05 20:54:35 -0500, Corey Huinker wrote:
> > It's been considered and not ruled out, with a "let's see how the simple
> > thing works, first" approach. Considerations are:
>
> Apologies if this has already been considered upthread, but would it be
> possible to use one query to gather all the required information into a
> sorted table? At a glance, it looks to me like it might be feasible. I
> had a lot of luck with reducing the number per-object queries with that
>
> One fairly easy win would be to stop issuing getAttributeStats() for
> non-expression indexes. In most cases that'll already drastically cut down
> on
> the extra queries.
That does seem like an easy win, especially since we're already using
indexprs for some filters. I am concerned that, dow
>
> Also, we will need to think through the set of pg_dump options again. A
>> lot of our tools seem to assume that "if it's the default, we don't
>> need a way to ask for it explicitly", which makes it a lot harder to
>> ever change the default and keep a coherent set of options.
>>
>
> That's a g
>
> Independently of that, do we want to switch over to storing
> reltuples as a string instead of converting it? I still feel
> uncomfortable about the amount of baggage we added to pg_dump
> to avoid that.
I'm obviously a 'yes' vote for string, either fixed width buffer or
pg_strdup'd, for the
On Fri, Feb 28, 2025 at 4:25 PM Jeff Davis wrote:
> On Fri, 2025-02-28 at 14:56 -0600, Nathan Bossart wrote:
> > On Fri, Feb 28, 2025 at 12:54:03PM -0800, Jeff Davis wrote:
> > > (Aside: I assume everyone here agrees that pg_upgrade should
> > > transfer
> > > the stats by default.)
> >
> > That
On Thu, Feb 27, 2025 at 10:01 PM Corey Huinker
wrote:
> +--- error: relation is wrong type
>> +SELECT pg_catalog.pg_restore_relation_stats(
>> +'relation', 0::oid,
>> +'relpages', 17::integer,
>> +'reltuples&#x
>
> +--- error: relation is wrong type
> +SELECT pg_catalog.pg_restore_relation_stats(
> +'relation', 0::oid,
> +'relpages', 17::integer,
> +'reltuples', 400.0::real,
> +'relallvisible', 4::integer);
>
> Why do you need to specify all the stats (relpages, reltuples,
On Tue, Feb 25, 2025 at 1:31 AM jian he wrote:
> hi.
> the thread "Statistics Import and Export" is quite hot.
> so a new thread for some minor issue i found.
>
>
> static int
> _tocEntryRequired(TocEntry *te, teSection curSection, ArchiveHandle *AH)
> {
>
> if (strcmp(te->desc, "STATISTICS D
what was already there, etc.
* the set difference tests remain, as they proved extremely useful in
detecting undesirable side-effects during development
From f3087b04784d6853970bf41eb619281d72ce94bd Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Wed, 26 Feb 2025 21:02:44 -0500
Subject: [PAT
On Wed, Feb 26, 2025 at 4:46 PM Tom Lane wrote:
> Melanie Plageman writes:
> > I have a patch that is getting thwacked around by the churn in
> > stats_import.sql, and it occurred to me that I don't see why all the
> > negative tests for pg_restore_relation_stats() need to have all the
> > para
>
> I have a patch that is getting thwacked around by the churn in
> stats_import.sql, and it occurred to me that I don't see why all the
> negative tests for pg_restore_relation_stats() need to have all the
> parameters provided. For example, in both of these tests, you are
> testing the relation
On Wed, Feb 26, 2025 at 11:23 AM Tom Lane wrote:
> Jeff Davis writes:
> > I think you had mentioned upthread something about getting rid of the
> > table-driven logic, which is fine with me. Did you mean for that to
> > happen in this patch as well?
>
> Per Corey's description of the patch (I di
On Wed, Feb 26, 2025 at 12:05 AM Tom Lane wrote:
> Corey Huinker writes:
> > Just to confirm, we ARE able to assume dense packing of attributes in an
> > index, and thus we can infer the attnum from the position of the attname
> in
> > the aggregated array, and there&#x
On Tue, Feb 25, 2025 at 11:36 PM Tom Lane wrote:
> Corey Huinker writes:
> > My solution so far is to take allo the v11+ (SELECT array_agg...)
> functions
> > and put them into a LATERAL, two of them filtered by attstattarget > 0
> and
> > a new one aggregating att
>
> To my mind the next task is to get the buildfarm green again by
> fixing the expression-index-stats problem. I can have a go at
> that once Jeff pushes these patches, unless one of you are already
> on it?
>
Already on it, but I can step aside if you've got a clearer vision of how
to solve it
On Tue, Feb 25, 2025 at 9:00 PM Jeff Davis wrote:
> On Mon, 2025-02-24 at 09:54 -0500, Andres Freund wrote:
> > Have you compared performance of with/without stats after these
> > optimizations?
>
> On unoptimized build with asserts enabled, dumping the regression
> database:
>
> --no-statistic
On Tue, Feb 25, 2025 at 1:22 PM Jeff Davis wrote:
> On Mon, 2025-02-24 at 12:50 -0500, Tom Lane wrote:
> > Also, while working on the attached, I couldn't help forming the
> > opinion that we'd be better off to nuke pg_set_attribute_stats()
> > from orbit and require people to use pg_restore_attr
On Mon, Feb 24, 2025 at 4:30 PM Corey Huinker
wrote:
>
>>
>> After a bit of playing around, it seemed messy to make it into
>> a join, but we could replace the two array_agg sub-selects with
>> a single one:
>>
>> (SELECT pg_catalog.array_agg(ROW(attname, a
On Mon, Feb 24, 2025 at 4:07 PM Jeff Davis wrote:
> On Mon, 2025-02-24 at 15:40 -0500, Tom Lane wrote:
> > I'm a little suspicious whether that has any effect if you insert it
> > before set_pglocale_pgservice().
>
> Ah, right. Corey, can you please include that (in the right place, of
> course)
On Mon, Feb 24, 2025 at 4:33 PM Andres Freund wrote:
> Hi,
>
> On February 24, 2025 10:30:08 PM GMT+01:00, Corey Huinker <
> corey.huin...@gmail.com> wrote:
> >From what I can see, it doesn't. Moreover, the attstattarget array agg is
> >only done in version
>
>
>
> After a bit of playing around, it seemed messy to make it into
> a join, but we could replace the two array_agg sub-selects with
> a single one:
>
> (SELECT pg_catalog.array_agg(ROW(attname, attstattarget) ORDER BY attnum)
> FROM pg_catalog.pg_attribute WHERE attrelid = i.indexrelid)
>
> a
>
> I don't think that's necessarily true, hot pruning might help some, as
> afaict
> the restore happens in multiple transactions.
>
If we're willing to take the potential bloat to avoid a nasty complexity,
then I'm all for discarding it. Jeff just indicated off-list that he isn't
seeing noticeab
On Mon, Feb 24, 2025 at 2:36 PM Tom Lane wrote:
> Corey Huinker writes:
> > Sadly, that attnum isn't available in pg_stats, so we'd have to
> reintroduce
> > the joins to pg_namespace and pg_class to get at pg_attribute, at least
> for
> > indexes.
>
>
>
>
>
> I suspect that this is a *really* bad idea. It's very very hard to get
> inplace
> updates right. We have several unfixed correctness bugs that are related to
> the use of inplace updates. I really don't think it's wise to add
> additional
> interfaces that can reach inplace updates unless
On Mon, Feb 24, 2025 at 1:54 PM Jeff Davis wrote:
> On Mon, 2025-02-24 at 13:47 -0500, Corey Huinker wrote:
> > There doesn't seem to be any way around it, but it will
> > slightly complicate the dump-ing side of things, in that we need to
> > either:
> >
&g
On Mon, Feb 24, 2025 at 12:51 PM Tom Lane wrote:
> Andres Freund writes:
> > On 2025-02-24 05:11:48 -0500, Corey Huinker wrote:
> >> * relpages/reltuples/relallvisible are now char[32] buffers in
> RelStatsInfo
> >> and nowhere else (existing relpages conversion r
On Mon, Feb 24, 2025 at 9:54 AM Andres Freund wrote:
> Hi,
>
> On 2025-02-24 05:11:48 -0500, Corey Huinker wrote:
> > Incorporating most of the feedback (I kept a few of
> > the appendNamedArgument() calls) presented over the weekend.
> >
> > * removeVer
oved to end of both queries for consistency.
From 95127f6fd82bde843e5840de93678ff784750c8a Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Mon, 24 Feb 2025 02:38:22 -0500
Subject: [PATCH v2 1/3] Leverage existing functions for relation stats.
Rather than quer pg_class once per relation in order to
On Sun, Feb 23, 2025 at 7:22 PM Jeff Davis wrote:
> On Sat, 2025-02-22 at 00:00 -0500, Corey Huinker wrote:
> >
> > Attached is the first optimization, which gets rid of the pg_class
> > queries entirely, instead getting the same information from the
> > existi
moteVersionStr is "18devel" rather than
"18".
I didn't include any work on the attribute query as I wanted to keep that
separate for clarity purposes.
From 45467a69813cbf25c2850b254c5d2710c231a723 Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Fri, 21 Feb 2025 23
>
> Oy. Those are outright horrid, even without any consideration of
> pre-preparing them. We know the OID of the table we want to dump,
> we should be doing "FROM pg_class WHERE oid = whatever" and lose
> the join to pg_namespace altogether. The explicit casts to regclass
> are quite expensive
en yes, we could trim it down, but as it is I think it's a
limitation of the testing structure. But aside from creating a whole extra
XYZ_pg_dump.pl file, I don't think there's a way to do that.
The previous 0001 is now committed (thanks!) so only one remains.
From afb3d0fd81fb
actually meant for any dump that
has all schema excluded.
From 2de404f8187466061469abfaf3a773290cce6af8 Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Tue, 21 Jan 2025 11:52:58 -0500
Subject: [PATCH v47 1/2] Lock table first when setting index relation
statistics.
Jian He reported [1] a missing lock relation bug
rding has been done, some of which I'm still not totally satisfied with,
so I'm going to give it another look tomorrow, but am putting this out for
reviewers in the mean time.
From fb095b7ea75ef366eaae5eb7b5322b9869a760ea Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Tue, 21 Jan 2025 11:
On Mon, Jan 27, 2025 at 11:09 AM Corey Huinker
wrote:
> On Mon, Jan 27, 2025 at 9:05 AM jian he
> wrote:
>
>> On Tue, Jan 21, 2025 at 7:31 AM Jeff Davis wrote:
>> >
>> > On Mon, 2025-01-20 at 16:45 -0500, Corey Huinker wrote:
>> > >
>> &g
On Sat, Jan 25, 2025 at 10:02 AM Corey Huinker
wrote:
> Fixed. Holding off on posting updated patch pending decision on what's the
>>> best thing to do with partitioned indexes.
>>
>>
> Though I was able to get it to work multiple ways, the one that seems to
>
>
>
> Hmmm, yeah. But that's only for the INNER JOIN case. But I've seen many
> of these star join queries with LEFT JOIN too, and then the FKs are not
> needed. All you need is a PK / unique index on the other side.
Indeed, many installations specifically _remove_ foreign keys because of
the dre
On Wed, Jan 29, 2025 at 2:50 AM jian he wrote:
> hi.
>
> select '{"1, 0B100101":"NaN"}'::pg_ndistinct;
> pg_ndistinct
>
> {"1, 37": -2147483648}
> (1 row)
>
I think my initial reaction is to just refuse those special values, but
I'll look into the parsing code to
On Tue, Jan 28, 2025 at 11:25 AM jian he
wrote:
> hi.
> I reviewed 0001 only.
>
> in src/backend/statistics/mvdistinct.c
>
> no need #include "nodes/pg_list.h" since
> src/include/statistics/statistics.h sub level include "nodes/pg_list.h"
>
> no need #include "utils/palloc.h"
> sicne #include "p
>
> I'd like to merge these down to 3 patches again, but I'm keeping them
> separate for this patchset to isolate the attnum-checking code for this
> go-round.
>
These are mock-ups of the to/from JSON functions, but building from/to text
rather than the not-yet-committed pg_ndistinct and pg_depend
On Mon, Jan 27, 2025 at 9:05 AM jian he wrote:
> On Tue, Jan 21, 2025 at 7:31 AM Jeff Davis wrote:
> >
> > On Mon, 2025-01-20 at 16:45 -0500, Corey Huinker wrote:
> > >
> > > What I struggle to understand is how that purpose isn't served better
> >
>
> Thoughts?
>
I don't have anything to add to what Nathan said, but thought I should say
so since this thread was broken off from my earlier thread. Eagerly
awaiting feedback.
>
> I see there's a couple MCV-specific functions in the extended_stats.c.
>> Shouldn't those go into mvc.c instead?
>>
>
> I wanted to put it there, but there was a reason I didn't and I've now
> forgotten what it was. I'll make an effort to relocate it to mcv.c.
>
Looking at it now, I see that c
>
>
>
> > * no negative attnums in key list
>
Disregard this suggestion - negative attnums mean the Nth expression in the
extended stats object, though it boggles the mind how we could have 222
expressions...
> > * no duplicate attnums in key list
>
This one is still live, am considering.
At
On Wed, Jan 22, 2025 at 5:50 PM Tomas Vondra wrote:
> Hi,
>
> Thanks for continuing to work on this.
>
> On 1/22/25 19:17, Corey Huinker wrote:
> > This is a separate thread for work started in [1] but focused purely on
> > getting the following functions working:
>
to break as many things as they fix, so I'm still working on
them.
From 40ec06c622c4be1de0e87509b2655e1d3ff62b4b Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Tue, 21 Jan 2025 11:52:58 -0500
Subject: [PATCH v43 1/2] Lock table first when setting index relation
statistics.
Jian He rep
>
>
>>
>>
> Sorry about that, my nvim config is auto-including stuff and it's annoying.
>
>
Now with less includes and fewer typos:
From 93e67e5304132e680b628b3e92f9fd242d998abd Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Tue, 21 Jan 2025 11:52:58 -0500
>
>
>
>
> /*
> * For indexes, we follow what do_analyze_rel() does so as to avoid any
> * deadlocks with analyze/vacuum, which is to take out a
> * ShareUpdateExclusive on table/matview first and only after that take
> * a a AccessShareLock on the index itself.
> */
> t
On Mon, Jan 20, 2025 at 10:59 PM Corey Huinker
wrote:
> Are you saying that there is a path for a partitioned index to have
>> stats today? If so, we can just follow that locking protocol. If not,
>> I'm concerned about trying to define the locking protocol for doing so
&g
>
> Are you saying that there is a path for a partitioned index to have
> stats today? If so, we can just follow that locking protocol. If not,
> I'm concerned about trying to define the locking protocol for doing so
> as a side-effect of this work.
>
A quick test on v17 indicates that, no, there
>
>
> Let's just block updating stats for partitioned indexes
> until there's a defined way to do so.
>
-1.
That will break pg_upgrade tests if there's any statistics out there for
any partitioned index.
> Also, we should check privileges on the right object, consistent with
> how ANALYZE does
Updated attached, burning numbers in the stats-sequence even though the
pg_dump patches have been left out for the time being.
From 03a15471b0f5a6776331d430cca2df619047271b Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Mon, 20 Jan 2025 16:18:51 -0500
Subject: [PATCH v40] Lock table first whe
>
> I believe you are referring to Tom's statement that "it'll be a
> serious, serious error for [stats] not to be SECTION_DATA". The
> statement is somewhat softened by the sentence that follows, and
> slightly more by [2]. But it's pretty clear that SECTION_POST_DATA is,
> at best, an implementat
hat
Attached is the patch, along with the regression test output prior to the
change to stat_utils.c.
Other pg_dump work has been left out of v39 to focus on this.
regression.diffs
Description: Binary data
From a86d16c6413e624d7785c8347fe4e9fbf9a8ce66 Mon Sep 17 00:00:00 2001
From: Corey Hu
On Mon, Jan 20, 2025 at 3:22 AM jian he wrote:
> On Thu, Jan 16, 2025 at 4:56 AM Corey Huinker
> wrote:
> >>
> >>
> >>
> >> I do like the idea of a "Statistics for ..." prefix, and I think it's
> >> doable.
> >
> >
>
> pg_dump --dbname=src2 --table=tenk1 --statistics-only --verbose > x.sql
> there no pg_restore_attribute_stats, pg_restore_relation_stats there
> for table tenk1.
> There aren't any statistics, should there be?
>
pg_restore_relation_stats: yes. looking into that.
pg_restore_attribute_stats: yes
will set me straight.
Attached is just the pg_dump stuff, and only for relation/attribute stats.
The extended stats and vacuumdb work will be in their own threads going
forward.
From fdb53409458bc9aeed3496f355173ac97062afd1 Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Sat, 16 Mar 2024 1
>
>
> Comments are not quite accurate, but I'll look at cleaning them up and
> adding them.
>
Much appreciated. Also, I don't think we need all of the comments, but I
figured it was easier for me to comment at every possible good place, and
let you pick your favorites.
>
>
> I like the description "STATISTICS DATA" because it differentiates from
>
You have Tomas to thank for that:
https://www.postgresql.org/message-id/bf724b21-914a-4497-84e3-49944f9776f6%40enterprisedb.com
the extended stats definitions. It might be worth differentiating
> between "RELATION ST
o help the next person come to that conclusion
sooner than I did.
From 84a8990622a4b83729600d9db43e8678502548f5 Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Fri, 20 Dec 2024 05:08:50 -0500
Subject: [PATCH v1] Explain impact of need_escapes in JSON parsing.
Adding some additional comments t
>
> The biggest functional change is the way dependencies are handled for
> matview stats. Materialized views ordinarily end up in
> SECITON_PRE_DATA, but in some cases they can be postponed to
> SECTION_POST_DATA. You solved that by always putting the matview stats
> in SECTION_POST_DATA.
>
Accur
pg_dump/pg_upgrade
0006 - attribute stats optimization
0007-0012 - vacuumdb
On Wed, Dec 11, 2024 at 10:49 PM Corey Huinker
wrote:
> +1, assuming such an option is wanted at all. I suppose it should be
>> there for the unlikely (and hopefully impossible) case that statistics
>>
relpages looks increasingly unlikely.
From c10e1c1f87bc8039dfae38077d6b37446bcf408d Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Thu, 14 Nov 2024 04:58:17 -0500
Subject: [PATCH v34 02/11] Add --no-data option.
This option is useful for situations where someone wishes to test
query plans from a prod
On Sat, Dec 7, 2024 at 2:27 PM Jeff Davis wrote:
> On Tue, 2024-11-26 at 17:11 -0500, Corey Huinker wrote:
> >
> > > * Why does binary upgrade cause statistics to be dumped? Can you
> > > just
> > > make pg_upgrade specify the appropriate set of flags?
> &g
>
>
> LGTM, I didn't scan for omissions but the ones in the patch look right to
> me.
> I sort of wish we had a shorter macro as CppAsString2() get's pretty
> verbose
> when used frequently like this.
>
I don't quite understand the etymology of the name (it's some variation on
C++'s std::to_string
1 - 100 of 446 matches
Mail list logo
