Re: Why not represent "never vacuumed" accurately wrt pg_class.relpages?
От | Tom Lane |
---|---|
Тема | Re: Why not represent "never vacuumed" accurately wrt pg_class.relpages? |
Дата | |
Msg-id | 4006.1544553827@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Why not represent "never vacuumed" accurately wrtpg_class.relpages? (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Why not represent "never vacuumed" accurately wrtpg_class.relpages?
|
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > On 2018-12-11 09:47:38 -0500, Tom Lane wrote: >> And why do you blame it on this representation? We don't believe that >> relpages is the actual size of the table. > No, but we assume that there's 10 pages. Even if both relpages and the > actual relation stats say there's not. And we assume there's as many > tuples on the page as can fit on it, using get_rel_data_width(). So if > you have a small table with a handful of entries at most, you suddenly > get estimates of a few hundred to ~a thousand rows. That's intentional, and not particularly constrained by the representation used in pg_class. The downsides of incorrectly assuming a table is tiny are a lot worse than those of assuming the opposite. > I guess you could argue that the relation would potentially not be be > empty anymore by the time the plan is executed, but if that were part of > the logic it a) wouldn't just be relevant if relpages = 0, and b) should > be documented. Yeah, that's the case where you can get hurt the worst. As for "not documented", the first para in the comment is trying to say that. regards, tom lane
В списке pgsql-hackers по дате отправления: