Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jk9cK-0004iL-R2 for pgsql-performance@arkaria.postgresql.org; Sat, 13 Jun 2020 17:06:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jk9cJ-0007pD-K7 for pgsql-performance@arkaria.postgresql.org; Sat, 13 Jun 2020 17:06:51 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jk9cJ-0007p6-D9 for pgsql-performance@lists.postgresql.org; Sat, 13 Jun 2020 17:06:51 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jk9cH-0003q4-A7 for pgsql-performance@postgresql.org; Sat, 13 Jun 2020 17:06:50 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 05DH6kfV845805; Sat, 13 Jun 2020 13:06:47 -0400 From: Tom Lane To: David Rowley cc: regrog , pgsql-performance Subject: Re: view reading information_schema is slow in PostgreSQL 12 In-reply-to: References: <1591975278775-0.post@n3.nabble.com> <798686.1592017869@sss.pgh.pa.us> <800752.1592021253@sss.pgh.pa.us> Comments: In-reply-to David Rowley message dated "Sat, 13 Jun 2020 20:22:09 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <845803.1592068006.1@sss.pgh.pa.us> Date: Sat, 13 Jun 2020 13:06:46 -0400 Message-ID: <845804.1592068006@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk David Rowley writes: > On Sat, 13 Jun 2020 at 19:52, David Rowley wrote: >> On Sat, 13 Jun 2020 at 16:07, Tom Lane wrote: >>> Hm. Maybe we could reasonably assume that the equality operators used >>> for such constructs are error-and-side-effect-free, thus dodging the >>> semantic problem I mentioned in the other thread? >> I'm only really talking about selectivity estimation only for now. >> I'm not really sure why we'd need to ensure that the equality operator >> is error and side effect free. We'd surely only be executing the case >> statement's operator's oprrest function? We'd need to ensure we don't >> invoke any casts that could error out. > Hmm, after a bit of thought I now see what you mean. No, you were right the first time: we're considering different things. I was wondering about how to constant-fold a "CASE = constant" construct as was being requested in the other thread. Obviously, if that succeeds then it'll simplify selectivity estimation too --- but it's reasonable to also think about what to do for "CASE = constant" in selectivity estimation, because with or without such a constant-folding rule, there would be lots of cases that the rule fails to simplify. Further we should be thinking about how to get some estimate for cases that the folding rule would fail at, so I'm not sure that we ought to restrict our thoughts to constant comparisons. In the cases I've seen so far, even a rule as dumb as "if the CASE has N arms then estimate selectivity as 1/N" would be a lot better than what we get now. regards, tom lane