Re: list of extended statistics on psql - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: list of extended statistics on psql
Date
Msg-id 29e16ceb-8777-4297-19c8-245242dd7473@enterprisedb.com
Whole thread Raw
In response to Re: list of extended statistics on psql  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: list of extended statistics on psql  (Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp>)
List pgsql-hackers

On 1/8/21 1:14 AM, Tomas Vondra wrote:
> 
> 
> On 1/8/21 12:52 AM, Tatsuro Yamada wrote:
>> Hi,
>>
>> On 2021/01/08 0:56, Tomas Vondra wrote:
>>> On 1/7/21 3:47 PM, Alvaro Herrera wrote:
>>>> On 2021-Jan-07, Tomas Vondra wrote:
>>>>
>>>>> On 1/7/21 1:46 AM, Tatsuro Yamada wrote:
>>>>
>>>>>> I overlooked the check for MCV in the logic building query
>>>>>> because I created the patch as a new feature on PG14.
>>>>>> I'm not sure whether we should do back patch or not. However, I'll
>>>>>> add the check on the next patch because it is useful if you decide to
>>>>>> do the back patch on PG10, 11, 12, and 13.
>>>>>
>>>>> BTW perhaps a quick look at the other \d commands would show if
>>>>> there are
>>>>> precedents. I didn't have time for that.
>>>>
>>>> Yes, we do promise that new psql works with older servers.
>>>>
>>>
>>> Yeah, makes sense. That means we need add the check for 12 / MCV.
>>
>>
>> Ah, I got it.
>> I fixed the patch to work with older servers to add the checking
>> versions. And I tested \dX command on older servers (PG10 - 13).
>> These results look fine.
>>
>> 0001:
>>       Added the check code to handle pre-PG12. It has not MCV and
>>        pg_statistic_ext_data.
>> 0002:
>>       This patch is the same as the previous patch (not changed).
>>
>> Please find the attached files.
>>
> 
> OK, thanks. I'll take a look and probably push tomorrow. FWIW I plan to
> squash the patches into a single commit.
> 

Attached is a patch I plan to commit - 0001 is the last submitted
version with a couple minor tweaks, mostly in docs/comments, and small
rework of branching to be more like the other functions in describe.c.

While working on that, I realized that 'defined' might be a bit
ambiguous, I initially thought it means 'NOT NULL' (which it does not).
I propose to change it to 'requested' instead. Tatsuro, do you agree, or
do you think 'defined' is better?


regards

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

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Enhance traceability of wal_level changes for backup management
Next
From: Tomas Vondra
Date:
Subject: Re: PoC/WIP: Extended statistics on expressions