Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> However, maybe views are not the best / most common example to think
> about. I'd imagine it's much more common to reference a regular table,
> but the table gets truncated / populated quickly, and/or the autovacuum
> workers are busy so it takes time to update reltuples. But in this case
> it's also quite simple to fix the correlation by just ordering by ctid
> (which I guess we might do based on the relkind).
> There's a minor issue with partitioned tables, with foreign partitions
> pointing to remote views. This is kinda broken, because the sample size
> for individual relations is determined based on relpages. But that's 0
> for views, so these partitions get ignored when building the sample. But
> that's a pre-existing issue.
I wonder if we should stop consulting reltuples directly at all,
and instead do
"EXPLAIN SELECT * FROM remote_table"
to get the remote planner's estimate of the number of rows involved.
Even for a plain table, that's likely to be a better number.
regards, tom lane