Re: Why not represent "never vacuumed" accurately wrt pg_class.relpages? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Why not represent "never vacuumed" accurately wrt pg_class.relpages?
Date
Msg-id 7951.1544539658@sss.pgh.pa.us
Whole thread Raw
In response to Why not represent "never vacuumed" accurately wrt pg_class.relpages?  (Andres Freund <andres@anarazel.de>)
Responses Re: Why not represent "never vacuumed" accurately wrtpg_class.relpages?  (Andres Freund <andres@anarazel.de>)
Re: Why not represent "never vacuumed" accurately wrt pg_class.relpages?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> I don't quite get why we don't instead just represent "never vacuumed"
> by storing a more meaningful value in relpages?

Mostly, not wanting to break clients that look at these fields.
If catalog compatibility weren't a concern, I'd seriously consider
replacing both of them with a float "average tuples per page" ratio.

> We could go for
> InvalidBlockNumber, or even NULL (although the latter would be a bit
> annoying due to not being mappable to a struct anymore).

NULL seems right out on every ground.  I don't much care for
InvalidBlockNumber either.

> I've seen numerous cases where relpages = 0 -> never vacuumed has caused
> worse plans, and it just doesn't seem necessary?

Worse plans than what?  And why do you blame it on this representation?
We don't believe that relpages is the actual size of the table.

            regards, tom lane


pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: Add timeline to partial WAL segments
Next
From: Pablo Iranzo Gómez
Date:
Subject: Re: Introducing SNI in TLS handshake for SSL connections