Re: Statistics Import and Export - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Statistics Import and Export
Date
Msg-id 699e79d831276054266cb2475e072df18d081cf8.camel@j-davis.com
Whole thread Raw
In response to Statistics Import and Export  (Corey Huinker <corey.huinker@gmail.com>)
Responses Re: Statistics Import and Export
List pgsql-hackers
On Thu, 2024-12-19 at 21:23 -0800, Jeff Davis wrote:
> > 0001-0005 - changes to pg_dump/pg_upgrade
>
> Attached is a version 36j...

The testing can use some work here. I noticed that if I take out the
stats entirely, the tests still pass, because pg_upgrade still gets the
same before/after result.

Also, we need some testing of the output and ordering of pg_dump.
Granted, in most cases problems would result in errors during the
reload. But we have those tests for other kinds of objects, so we
should have the tests for stats, too.

I like the description "STATISTICS DATA" because it differentiates from
the extended stats definitions. It might be worth differentiating
between "RELATION STATISTICS DATA" and "ATTRIBUTE STATISTICS DATA" but
I'm not sure if there's value in that.

But how did you determine what to use for the .tag and prefix? In the
output, it uses the form:

  Name: STATISTICS DATA <name>; Type: STATISTICS DATA; ...

Should that be:

  Name: <name>; Type: STATISTICS DATA; ...

Or:

  Data for Name: ...; Name: ...; Type: STATISTICS DATA; ...

Or:

  Statistics for Name: ...; Name: ...; Type: STATISTICS DATA; ...

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Bug: mdunlinkfiletag unlinks mainfork seg.0 instead of indicated fork+segment
Next
From: Matthias van de Meent
Date:
Subject: Re: a litter question about mdunlinkfiletag function