Re: Psql patch to show access methods info - Mailing list pgsql-hackers

From s.cherkashin@postgrespro.ru
Subject Re: Psql patch to show access methods info
Date
Msg-id 1e7dee71706c55edbdbac795cd5109d1@postgrespro.ru
Whole thread Raw
In response to Re: Psql patch to show access methods info  (Nikita Glukhov <n.gluhov@postgrespro.ru>)
Responses Re: Psql patch to show access methods info  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Following issues are solved:

>> \dAf[+]  [AMPTRN [OPFPTRN]]  list operator families of access method. 
>> +
>> prints owner of operator family. (Table pg_opfamily)
> 
>> \dAfp    [AMPTRN [OPFPTRN]]  list procedures of operator family 
>> related
>> to access method (Table pg_amproc)
> 
>  * Reorder "Left"/"Right" and "Strategy"/"Proc name" columns.
>  * Include "Left"/"Right" columns into ORDER BY clause.
>  * Show procedure's argument types, because procedure's name does not 
> completely
>    identify procedure (for example, in_range() is used in several 
> opclasses with
>    different signatures).  Or maybe show arguments only if procedure 
> name is not
>    unique?
> 
>> \dAfo    [AMPTRN [OPFPTRN]]  list operators of family related to 
>> access
>> method (Table pg_amop)
> 
>  * Reorder "Left"/"Right" and "Strategy"/"Operator" columns.
>  * Include "Left"/"Right" columns into ORDER BY clause.

>> \dAoc[+] [AMPTRN [OPCPTRN]]  list operator classes of index access
>> methods. + prints owner of operator class. (Table pg_opclass)
> 
>  * Maybe it would be better to show stored type only if it differs from 
> the
>    indexed type?
> 
>> \dip[S]  [PATTERN]           list indexes with properties (Table
>> pg_class)
> 
>> \dicp[S] [IDXNAME [COLNAME]] show index column properties (Table
>> pg_class)
> 
>  * Fix duplicate rows that appear in the table for composite indices.
>  * Include "Column #" into ORDER BY clause.
>  * Rename column "Null first" to "Nulls First" or "NULLS LAST".
>  * Maybe it is not necessary to show "Access method" column here?
>  * I think we should show column's properties in the separate table for 
> each
>    index, because it is not so easy to understand the combined table.


Following issues require discussion:
>> \dAp  
>  * Should we rename it to \dAip and include "index" word into the table 
> header?
>    As you know, we are going to support table AMs in the future.

>> \dAfo
>  * Operator's schema is shown only if operator is invisible for the 
> current
>    user -- I'm not sure if this is correct.
    \dAfo and \dAfp
    * Should we put info in separate table for each Operator family?


>> \dicp
>  * ASC, NULLS are shown as TRUE/FALSE only if the index is orderable, 
> and as
>    NULL if unorderable -- I'm not sure if this is correct.  Maybe we 
> should
>    simply show these properties in the literal form, not as booleans
>    (as strings 'ASC'/'DESC', 'NULLS FIRST'/'NULLS LAST')?

> 
>> I also have a question about testing commands \dAf+ and \dAoc+: is it
>> good idea to test them by changing an owner of one operator family or
>> class to created new one, checking the output, and restoring the owner
>> back? Or we should create a new opclass or opfamily with proper owner.
>> Or maybe it is not necesary to test these commands?

Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Avoid extra Sort nodes between WindowAggs when sorting can be reused
Next
From: Masahiko Sawada
Date:
Subject: Re: Threat models for DB cryptography (Re: [Proposal] Table-levelTransparent Data Encryption (TDE) and Key) Management Service (KMS)