Re: Psql patch to show access methods info

From: Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>
To: Sergey Cherkashin <s(dot)cherkashin(at)postgrespro(dot)ru>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Psql patch to show access methods info
Date: 2018-06-25 22:26:18
Message-ID: 854decee-0244-c69d-2287-74ae260a574d@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On 22.06.2018 16:48, Sergey Cherkashin wrote:

> Hello!
>
> There are command in psql to list access methods, but there are no fast
> way to look detailed info about them. So here a patch with new
> commands:

Hi!

I've done a preliminary in-company review of this patch several times.
Here is my review of its first published version.

> \dAp     [PATTERN]           list access methods with properties (Table
> pg_am)

* 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.

> \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.
* Operator's schema is shown only if operator is invisible for the current
user -- I'm not sure if this is correct.

> \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?
* 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 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.
The same, perhaps, can be applied to \dAfp and \dAfo commands.

> 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?
--
Nikita Glukhov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2018-06-25 22:48:23 Re: Performance regression with PostgreSQL 11 and partitioning
Previous Message Alvaro Herrera 2018-06-25 21:25:23 Re: Fix slot's xmin advancement and subxact's lost snapshots in decoding.