Message-ID: <4e49c72e-f8a5-de1a-4ef4-36529bee1d65@enterprisedb.com>
Date: Wed, 27 Dec 2023 13:08:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.1
Subject: Re: Statistics Import and Export
Content-Language: en-US
To: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <bruce@momjian.us>
Cc: Corey Huinker <corey.huinker@gmail.com>,
 Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
 pgsql-hackers@lists.postgresql.org
References: 
 <CADkLM=cB0rF3p_FuWRTMSV0983ihTRpsH+OCpNyiqE7Wk0vUWA@mail.gmail.com>
 <CAExHW5uRNe856LPYH1eZFyeASv4Xs4-9d1Gqj+rzS+3StVGLxQ@mail.gmail.com>
 <CADkLM=c_iuAN19_94ikG5VeR_Z3LDkR6fKyeOz=ZKr44qweYjg@mail.gmail.com>
 <CADkLM=dTHVSrcGBAstjshoZBXKJgWjzN3Vj53KQ9fORqvkaN5Q@mail.gmail.com>
 <f0930823-d44b-21df-d718-ee3c657d9087@enterprisedb.com>
 <CADkLM=cx-XM-PTscj+uDi24x3_vDpYMOjfHgw9CFt_ad5poc0A@mail.gmail.com>
 <76596388-6fe6-0baf-351d-734458a46d76@enterprisedb.com>
 <CADkLM=frTx5DocOpyhRHL4r_LKvP315cNA-5+0UVqGM=7GKd9A@mail.gmail.com>
 <4268d862-7784-f76f-d7f1-359b0b4db67c@enterprisedb.com>
 <ZYsYMqukg97HdB7u@momjian.us> <2090613.1703618344@sss.pgh.pa.us>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
In-Reply-To: <2090613.1703618344@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/4e49c72e-f8a5-de1a-4ef4-36529bee1d65%40enterprisedb.com>
Precedence: bulk

On 12/26/23 20:19, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
>> I think we need a robust API to handle two cases:
> 
>> *  changes in how we store statistics
>> *  changes in how how data type values are represented in the statistics
> 
>> We have had such changes in the past, and I think these two issues are
>> what have prevented import/export of statistics up to this point.
>> Developing an API that doesn't cleanly handle these will cause long-term
>> pain.
> 
> Agreed.
> 

I agree the format is important - we don't want to end up with a format
that's cumbersome or inconvenient to use. But I don't think the proposed
format is somewhat bad in those respects - it mostly reflects how we
store statistics and if I was designing a format for humans, it might
look a bit differently. But that's not the goal here, IMHO.

I don't quite understand the two cases above. Why should this affect how
we store statistics? Surely, making the statistics easy to use for the
optimizer is much more important than occasional export/import.

>> In summary, I think we need an SQL-level command for this.
> 
> I think a SQL command is an actively bad idea.  It'll just add development
> and maintenance overhead that we don't need.  When I worked on this topic
> years ago at Salesforce, I had things set up with simple functions, which
> pg_dump would invoke by writing more or less
> 
> 	SELECT pg_catalog.load_statistics(....);
> 
> This has a number of advantages, not least of which is that an extension
> could plausibly add compatible functions to older versions.  The trick,
> as you say, is to figure out what the argument lists ought to be.
> Unfortunately I recall few details of what I wrote for Salesforce,
> but I think I had it broken down in a way where there was a separate
> function call occurring for each pg_statistic "slot", thus roughly
> 
> load_statistics(table regclass, attname text, stakind int, stavalue ...);
> 
> I might have had a separate load_statistics_xxx function for each
> stakind, which would ease the issue of deciding what the datatype
> of "stavalue" is.  As mentioned already, we'd also need some sort of
> version identifier, and we'd expect the load_statistics() functions
> to be able to transform the data if the old version used a different
> representation.  I agree with the idea that an explicit representation
> of the source table attribute's type would be wise, too.
> 

Yeah, this is pretty much what I meant by "functional" interface. But if
I said maybe the format implemented by the patch is maybe too close to
how we store the statistics, then this has exactly the same issue. And
it has other issues too, I think - it breaks down the stats into
multiple function calls, so ensuring the sanity/correctness of whole
sets of statistics gets much harder, I think.

I'm not sure about the extension idea. Yes, we could have an extension
providing such functions, but do we have any precedent of making
pg_upgrade dependent on an external extension? I'd much rather have
something built-in that just works, especially if we intend to make it
the default behavior (which I think should be our aim here).


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company