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