Re: planstats.sgml - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: planstats.sgml
Date
Msg-id CAKFQuwYWg4WZ+v1eSUAq76HcnSZjyed4AmdwaT9C67AkD=8fdQ@mail.gmail.com
Whole thread Raw
In response to planstats.sgml  (Tatsuo Ishii <ishii@postgresql.org>)
Responses Re: planstats.sgml
List pgsql-hackers
On Mon, Feb 15, 2016 at 4:23 PM, Tatsuo Ishii <ishii@postgresql.org> wrote:
While reading planstats.sgml, I encounted a sentence which I don't
understand.

    These numbers are current as of the last <command>VACUUM</> or
    <command>ANALYZE</> on the table.  The planner then fetches the
    actual current number of pages in the table (this is a cheap operation,
    not requiring a table scan).  If that is different from
    <structfield>relpages</structfield> then
    <structfield>reltuples</structfield> is scaled accordingly to
    arrive at a current number-of-rows estimate.  In this case the value of
    <structfield>relpages</structfield> is up-to-date so the rows estimate is
    the same as <structfield>reltuples</structfield>.

I don't understand the last sentence (In this case...). For me it
seems it is talking about the case when replages is not different from
what the planner fetches from the table. If so, why "In this case"?
Isn't "In this case" referrers to the previous sentence (If that is
different from...)? Maybe "In this case" should be "Otherwise" or some
such?


​The whole sentence is awkward but you are correct in your reading - and "otherwise" would be a solid choice.

Though iIt seems the whole thing could be simplified to:

These numbers are current as of the last VACUUM or ANALYZE on the table.  To account for subsequent changes the planner obtains the actual page count for the table and scales pg_class.reltuples by a factor of "actual page count" over pg_class.relpages.

The "cheap operation" comment seems gratuitous though could still be injected if desired.

David J.


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Using quicksort for every external sort run
Next
From: Alvaro Herrera
Date:
Subject: Re: innocuous: pgbench does FD_ISSET on invalid socket