| 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: | Whole Thread | Raw Message | 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? |