Tomas Vondra <tomas.von...@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