On 2021-Apr-04, Tomas Vondra wrote:
> In fact, one of the first posts in this threads links to this:
>
> https://www.postgresql.org/message-id/4823.1262132964%40sss.pgh.pa.us
>
> i.e. Tom actually proposed doing something like this back in 2009, so
> presumably he though it's desirable back then.
>
> OTOH he argued against adding another per-table counter and proposed
> essentially what the patch did before, i.e. propagating the counter
> after analyze. But we know that may trigger analyze too often ...
Yeah, I think that's a doomed approach. The reason to avoid another
column is to avoid bloat, which is good but if we end up with an
unworkable design then we know we have to backtrack on it.
I was thinking that we could get away with having a separate pgstat
struct for partitioned tables, to avoid enlarging the struct for all
tables, but if we're going to also include legacy inheritance in the
feature clearly that doesn't work.
--
Álvaro Herrera Valdivia, Chile
"After a quick R of TFM, all I can say is HOLY CR** THAT IS COOL! PostgreSQL was
amazing when I first started using it at 7.2, and I'm continually astounded by
learning new features and techniques made available by the continuing work of
the development team."
Berend Tober, http://archives.postgresql.org/pgsql-hackers/2007-08/msg01009.php
