From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: James Coleman <jtc331@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Cc: Simon Riggs <simon@2ndquadrant.com>
Subject: Re: PROC_IN_ANALYZE stillborn 13 years ago
Date: Fri, 07 Aug 2020 14:41:41 -0400
Message-ID: <2793035.1596825701@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, andres@anarazel.de, alvherre@2ndquadrant.com, jtc331@gmail.com, pgsql-hackers@lists.postgresql.org, simon@2ndquadrant.com
Subject: Re: PROC_IN_ANALYZE stillborn 13 years ago
In-Reply-To: <2793035.1596825701@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox