Re: [PROPOSAL] Backup and recovery of pg_statistic

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Dmitry Ivanov <d(dot)ivanov(at)postgrespro(dot)ru>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PROPOSAL] Backup and recovery of pg_statistic
Date: 2015-12-23 00:14:34
Message-ID: 20151223001434.GA4222@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 27, 2015 at 06:52:59PM +0300, Dmitry Ivanov wrote:
> Proposed changes to pg_dump
> ===========================
>
> Now that the approach has been developed, it may be applied to improve the
> 'pg_dump' utility. Some minor code changes would make the 'pg_dump' emit
> specially-formed recovery INSERTS for 'pg_statistic' in the 'binary-upgrade'
> mode, thus allowing us to restore saved stats after an upgrade.

I think this is great. My only question for the list is how much does
this dumping create new compatibility requirements between major
versions. While pg_upgrade could disable it, pg_dump can't because it
doesn't know what PG version it is being loaded into. Can we create a
format that is portable to all future PG versions, or at least detect
incompatibility? I am thinking we would need some pg_statistic version
number in the dump data that can cause the data to be ignored.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2015-12-23 01:10:03 Re: Using quicksort for every external sort run
Previous Message Peter Geoghegan 2015-12-22 23:45:35 Re: A Typo in regress/sql/privileges.sql