Re: Why not represent "never vacuumed" accurately wrt pg_class.relpages?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Why not represent "never vacuumed" accurately wrt pg_class.relpages?
Date: 2018-12-11 18:43:47
Message-ID: 4006.1544553827@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-12-11 18:51:05 Re: Why not represent "never vacuumed" accurately wrt pg_class.relpages?
Previous Message Andres Freund 2018-12-11 18:23:31 Re: Why not represent "never vacuumed" accurately wrt pg_class.relpages?