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

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

Hi,

On 2018-12-11 13:59:55 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > How's being unable to distinguish "never vacuumed" from "table is
> > knowingly empty right now" not constrained by the representation?
>
> Well, OK, it is constrained, but even if it weren't I'd be afraid to
> assume a table is totally empty, even if it was so the last time
> ANALYZE looked at it. The plans you get from that are spectacularly
> fragile.

I think some clamping would be acceptable, but three orders of magnitude
off seems excessive. By clamping both the tuple density and the number
of pages, we're essentially multiplying the error.

But if this is your concern: Why are we believing that a previously
vacuumed table is actually empty if it was previously one block long
(relpages == 1), but not if it previously zero blocks long (relpages ==
0). In the former case we're entering the
/* quick exit if rel is clearly empty */
if (curpages == 0)
{
*tuples = 0;
*allvisfrac = 0;
break;
}
bit, but not in the latter case. Your fragility argument seems to hold
about as much sway there.

To me the whole logic around this largely seems to be cargo culting
things forward.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-12-11 19:28:50 Re: Why not represent "never vacuumed" accurately wrt pg_class.relpages?
Previous Message Chapman Flack 2018-12-11 19:04:17 Re: Record last password change