Re: planstats.sgml

From: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: planstats.sgml
Date: 2016-02-16 05:38:36
Message-ID: 56C2B5DC.4070007@catalyst.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 16/02/16 12:46, David G. Johnston wrote:
> On Mon, Feb 15, 2016 at 4:23 PM, Tatsuo Ishii <ishii(at)postgresql(dot)org
> <mailto:ishii(at)postgresql(dot)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.
>

A long while ago when I wrote that, I was expressing the fact that *in
the example* the numbers matched perfectly, but *in general* the planner
would scale 'em. It still reads that way to me...but change away if you
like :-)

> 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.
>

Well folk interested in performance, like to keep an eye on whether
these sort of probes cost a lot...

regards

Mark

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2016-02-16 06:06:34 Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)
Previous Message Pavel Stehule 2016-02-16 05:01:33 Re: custom function for converting human readable sizes to bytes