From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jim Nasby <jim@nasby.net>
cc: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Regression from 9.4-9.6
In-reply-to: <e0a4a8e6-d2e6-c6a8-dbb0-92131302bcbb@nasby.net>
References: <5d7c0f80-3767-1531-d911-197fcc147173@nasby.net>
 <11434.1507491291@sss.pgh.pa.us>
 <e0a4a8e6-d2e6-c6a8-dbb0-92131302bcbb@nasby.net>
Comments: In-reply-to Jim Nasby <jim@nasby.net>
	message dated "Sun, 08 Oct 2017 15:02:42 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <13825.1507495079.1@sss.pgh.pa.us>
Date: Sun, 08 Oct 2017 16:37:59 -0400
Message-ID: <13826.1507495079@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Jim Nasby <jim@nasby.net> writes:
> On 10/8/17 2:34 PM, Tom Lane wrote:
>> Why has this indexscan's cost estimate changed so much?

> Great question... the only thing that sticks out is the coalesce(). Let 
> me see if an analyze with a higher stats target changes anything. FWIW, 
> the 9.6 database is copied from the 9.4 one once a week and then 
> pg_upgraded. I'm pretty sure an ANALYZE is part of that process.

Hm, now that I see the SubPlan in there, I wonder whether 9.6 is
accounting more conservatively for the cost of the subplan.  It
probably is assuming that the subplan gets run for each row fetched
from the index, although the loops and rows-removed counts show
that the previous filter conditions reject 99% of the fetched rows.

But that code looks the same in 9.4, so I don't understand why
the 9.4 estimate isn't equally large ...

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance