From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Andres Freund <andres@anarazel.de>,
        Alvaro Herrera <alvherre@2ndquadrant.com>,
        James Coleman <jtc331@gmail.com>,
        pgsql-hackers <pgsql-hackers@lists.postgresql.org>,
        Simon Riggs <simon@2ndquadrant.com>
Subject: Re: PROC_IN_ANALYZE stillborn 13 years ago
In-reply-to: 
 <CA+TgmoZ8MJvdnv_VUHyJNPE=B8fuhUXyGcpXpA42qwS4jq0JGQ@mail.gmail.com>
References: <20200805021435.GA9523@alvherre.pgsql>
 <20200805235549.GA8118@alvherre.pgsql>
 <20200806010711.mzvu36zy25xer33t@alap3.anarazel.de>
 <CA+TgmoZn5oX4j3KXMkQx=RN+QBgc_y3+1LjBcy_afOmJb-f0-A@mail.gmail.com>
 <2637311.1596739058@sss.pgh.pa.us>
 <CA+Tgmob0veNwAikDiuWTHcTpQHdqAHFqqgf9ycg9dZyiWR30eg@mail.gmail.com>
 <2638833.1596741087@sss.pgh.pa.us>
 <CA+TgmoZ9hycF=fu0V+812fOvTsje5bCV6vMdDWphSANOiv-vqw@mail.gmail.com>
 <2647180.1596749733@sss.pgh.pa.us>
 <CA+TgmoZ8MJvdnv_VUHyJNPE=B8fuhUXyGcpXpA42qwS4jq0JGQ@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Fri, 07 Aug 2020 14:03:37 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2793034.1596825701.1@sss.pgh.pa.us>
Date: Fri, 07 Aug 2020 14:41:41 -0400
Message-ID: <2793035.1596825701@sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> Thinking about it more, there are really two ways to think about an
> estimated row count.

> On the one hand, if you think of the row count estimate as the number
> of rows that are going to pop out of a node, then it's always right to
> think of a unique index as limiting the number of occurrences of a
> given value to 1. But, if you think of the row count estimate as a way
> of estimating the amount of work that the node has to do to produce
> that output, then it isn't.

The planner intends its row counts to be interpreted in the first way.
We do have a rather indirect way of accounting for the cost of scanning
dead tuples and such, which is that we scale scanning costs according
to the measured physical size of the relation.  That works better for
I/O costs than it does for CPU costs, but it's not completely useless
for the latter.  In any case, we'd certainly not want to increase the
scan's row count estimate for that, because that would falsely inflate
our estimate of how much work upper plan levels have to do.  Whatever
happens at the scan level, the upper levels aren't going to see those
dead tuples.

			regards, tom lane