Re: Psql patch to show access methods info

From: s(dot)cherkashin(at)postgrespro(dot)ru
To: Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Psql patch to show access methods info
Date: 2018-07-03 10:25:37
Message-ID: 1e7dee71706c55edbdbac795cd5109d1@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
psql_add_am_info_v2.patch text/x-diff 43.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2018-07-03 10:28:42 Re: Threat models for DB cryptography (Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key) Management Service (KMS)
Previous Message Masahiko Sawada 2018-07-03 10:24:06 Re: Avoid extra Sort nodes between WindowAggs when sorting can be reused