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: | [email protected] |
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 |
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 |