Re: planstats.sgml
От | Mark Kirkwood |
---|---|
Тема | Re: planstats.sgml |
Дата | |
Msg-id | 56C2B5DC.4070007@catalyst.net.nz обсуждение исходный текст |
Ответ на | Re: planstats.sgml ("David G. Johnston" <david.g.johnston@gmail.com>) |
Список | pgsql-hackers |
On 16/02/16 12:46, David G. Johnston wrote: > On Mon, Feb 15, 2016 at 4:23 PM, Tatsuo Ishii <ishii@postgresql.org > <mailto: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. > 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
В списке pgsql-hackers по дате отправления: