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 1hw6cr-0002N1-0s for pgsql-performance@arkaria.postgresql.org; Fri, 09 Aug 2019 15:16:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hw6cp-0003XK-QQ for pgsql-performance@arkaria.postgresql.org; Fri, 09 Aug 2019 15:16:15 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hw6cp-0003TN-Cq for pgsql-performance@lists.postgresql.org; Fri, 09 Aug 2019 15:16:15 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1hw6cn-00078o-0D for pgsql-performance@lists.postgresql.org; Fri, 09 Aug 2019 15:16:14 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x79FG9JY008770; Fri, 9 Aug 2019 11:16:09 -0400 From: Tom Lane To: "Thomas Rosenstein" cc: pgsql-performance@lists.postgresql.org Subject: Re: Postgres not using correct indices for views. In-reply-to: References: <31061.1565280312@sss.pgh.pa.us> <27100.1565304307@sss.pgh.pa.us> Comments: In-reply-to "Thomas Rosenstein" message dated "Fri, 09 Aug 2019 09:32:06 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8768.1565363769.1@sss.pgh.pa.us> Date: Fri, 09 Aug 2019 11:16:09 -0400 Message-ID: <8769.1565363769@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk [ re-adding list ] "Thomas Rosenstein" writes: > On 9 Aug 2019, at 0:45, Tom Lane wrote: >> However ... it sort of looks like the planner didn't even consider >> the second plan shape in the "wrong" case. If it had, then even >> if it costed it 3X more than it did in the "right" case, the second >> plan would still have won out by orders of magnitude. So there's >> something else going on. >> >> Can you show the actual query and table and view definitions? > View definition: > SELECT l.id, > l.created_at, > ... > togdpr(l.comment) AS comment, > ... > FROM loans l; Ah-hah. I'd been thinking about permissions on the table and view, but here's the other moving part: functions in the view. I bet you were incautious about making this function definition and allowed togdpr() to be marked volatile --- which it will be by default. That inhibits a lot of optimizations. I'm guessing about what that function does, but if you could safely mark it stable or even immutable, I bet this view would behave better. regards, tom lane