After running GetForeignRelSize for a foreign table, adjust rel->tuples
to be at least as large as rel->rows. This prevents bizarre behavior
in estimate_num_groups() and perhaps other places, especially in the
scenario where rel->tuples is zero because pg_class.reltuples is
(suggesting that ANALYZE has never been run for the table). As things
stood, we'd end up estimating one group out of any GROUP BY on such a
table, whereas the default group-count estimate is more likely to result
in a sane plan.
Also, clarify in the documentation that GetForeignRelSize has the option
to override the rel->tuples value if it has a better idea of what to use
than what is in pg_class.reltuples.
Per report from Jeff Janes. Back-patch to all supported branches.
Patch by me; thanks to Etsuro Fujita for review
Discussion: https://postgr.es/m/CAMkU=1xNo9cnan+Npxgz0eK7394xmjmKg-QEm8wYG9P5-CcaqQ@mail.gmail.com
should be replaced if at all possible. The function may also choose to
update <literal>baserel->width</> if it can compute a better estimate
of the average result row width.
+ (The initial value is based on column data types and on column
+ average-width values measured by the last <command>ANALYZE</command>.)
+ Also, this function may update <literal>baserel->tuples</literal> if
+ it can compute a better estimate of the foreign table's total row count.
+ (The initial value is
+ from <structname>pg_class</structname>.<structfield>reltuples</structfield>
+ which represents the total row count seen by the
+ last <command>ANALYZE</command>.)
</para>
<para>
/* ... but do not let it set the rows estimate to zero */
rel->rows = clamp_row_est(rel->rows);
+
+ /* also, make sure rel->tuples is not insane relative to rel->rows */
+ rel->tuples = Max(rel->tuples, rel->rows);
}
/*