Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iAaZf-00035x-Ms for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Sep 2019 14:04:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iAaZe-00005p-Hs for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Sep 2019 14:04:50 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iAaZe-00005V-5F for pgsql-hackers@lists.postgresql.org; Wed, 18 Sep 2019 14:04:50 +0000 Received: from mail-qt1-x841.google.com ([2607:f8b0:4864:20::841]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iAaZa-0003RA-T9 for pgsql-hackers@postgresql.org; Wed, 18 Sep 2019 14:04:49 +0000 Received: by mail-qt1-x841.google.com with SMTP id j31so9024256qta.5 for ; Wed, 18 Sep 2019 07:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=XdR9/VR3rs8nmKywxzaR70E50RfZghG8Kbvkzjnlndo=; b=tk1NQKWcPjTdhUFBUtnaOr8vWVYVgmEO/OjnJldWFCEdYLcxncoqIcCBO602Ip/yET nGfEQIOPGCRyFoNyyKDDS9wA8SYnHfPm5NJ24YegmFV18LyFpzyECnfVw+G7hKxltAJA AsR4VpyngA08BOLlZIrYrVNQ4w7Bnx39u6F+r9KbDmy8RHpfCgQNOHgDU0DNvS5WPj7L aNQhd79tFWpD/HKugMv6jwjcPSsJ9hcYofwpX/FVAGFJaMvn5TKek1TpaKliZjysmoXP JaQ0IeADcb7WMk46VUUqnOkjotLgQMJv4Vw+NYO7ZDBNmDwMVSCGpmZbDiHcJdzMHzvZ 8IXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=XdR9/VR3rs8nmKywxzaR70E50RfZghG8Kbvkzjnlndo=; b=twbSQ0PwYnGElUbV0zYT4xoFYH8RoAqaAic+Zi3NypGU7r2dBRQp+qpfGOj1uO6cpi NR4OBRQxzvBr1ZwnBHrV/GKmIY3Ifw6AP3wZSNxOAcDFaGaLaV6HhvoYnNn/VqLCY7Ct cit3gsn61EDf0tDecglixT2E+rSPR4Z26ExpkIh3U7z4QRglnXP9BfQCH6OFSAbOzv8w SW7XBVnOX+7ZNO+Vf9bvRAgARdbELtPEJrnImssxOVoyMG0IxOHvgXlVe1NfuqhOcGUu vtI+qba7/XACWiTz+W/R8TEfUjzcZmsHZTRjBMTMm3QQ6zILnnnTMCIBSJ171+kM6DtZ 64PA== X-Gm-Message-State: APjAAAWcMDIgGmGcHXD3rwa73SlFQ8YIF8WVUS1fuT2HybLGign4YLzI UobGNvqs2HYMajcFQtYwu5VwlQ== X-Google-Smtp-Source: APXvYqz/LPCBjHBH2ezBpp/iCPDizgTRuFk2WIikDl32YR+A00DsGKqGEW2KETovCDZnJIR35QOXow== X-Received: by 2002:ac8:fcf:: with SMTP id f15mr4312878qtk.376.1568815485091; Wed, 18 Sep 2019 07:04:45 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([177.154.145.99]) by smtp.gmail.com with ESMTPSA id 56sm4912889qty.15.2019.09.18.07.04.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Sep 2019 07:04:44 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 6F17A120349; Wed, 18 Sep 2019 11:04:40 -0300 (-03) Date: Wed, 18 Sep 2019 11:04:40 -0300 From: Alvaro Herrera To: Alexander Korotkov Cc: Andres Freund , Nikita Glukhov , Thomas Munro , pgsql-hackers , Kyotaro HORIGUCHI , David Steele , Michael Paquier Subject: Re: Psql patch to show access methods info Message-ID: <20190918140440.GA28323@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Sep-18, Alexander Korotkov wrote: > On Tue, Sep 17, 2019 at 9:01 PM Alvaro Herrera wrote: > > I think \dAf is just as critical as \dAo; the former lets you know which > > opfamilies you can use in CREATE INDEX, while the latter lets you know > > which operators would be helped by such an index. (But, really, only if > > the opfamily name is printed in \d of the index, which we currently > > don't print unless it's non-default ... which is an omission that > > perhaps we should consider fixing). > I think you have a point. Will add \dAf command to the patch. Great, thanks. I think in order for this feature to be more complete "\d index" should show the opfamily name, also, even when it's the default one. (Let's not put the opfamily when it's the default in "\d table", as we do when the opfamily is not default; that would lead, I think, to too much clutter.) > > On the other hand, from a user perspective, what you really want to know > > is: what opfamilies exist for datatype T, and what operators are > > supported by the opfamily I have chosen? The current patch doesn't > > really help you find that out. I hope that in some future somebody will contribute towards this, which I think is more important (from users POV) than the below one: > > I think \dAp isn't terribly informative from a user perspective. The > > support procs are just an opfamily implementation detail. > > I've expressed my opinion regarding \dAp in [1]. In my observations, > some advanced users can write btree/hash opclasses in pl/* languages. > This doesn't require knowledge of core developer. And they may find > \dAp command useful. What do you think? I have never tried or had the need to do that. I'll take your word for it, so I have no objection. I do wonder if \? is going to end up with too much clutter, and if so do we need to make \? show only the most important commands and relegate some others to \?+ ... however, going over the existing \? I see no command that I would move to \?+ so \dAp would be alone there, which would be pretty strange. So let's forget this angle for now; but if psql acquires too much "system innards" functionality then I say we should consider it. Thanks -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services