> Indeed. So I think this is an uninteresting contrived case.
I agree the reproducer is contrived, and that assuming 10 pages for a never vacuumed table is the right call.
My concern is that ANALYZE does not always get us out of it. The n_distinct estimator is known to undershoot on long tailed columns.
I did a mini benchmark:
Take a 5M row orders table where half the rows come from 1000 big customers
and half from one time customers. Right after ANALYZE it gets n_distinct 31846, against a true value of 2.5M. A join of two such tables is estimated at 780M rows and returns 2.5M. That is one join, and each further join multiplies the error.
True, that sort of error should compound over multiple joins, and so the number
of rows.
Could you include your script?
So the same shape comes out of fresh statistics on an ordinary schema, and the extra cost only appeared in 18. That is why I think it is worth handling.
From:
PG Bug reporting form Date: Subject:
BUG #19711: SSH tunnel with PPK identity file fails/crashes in newer pgAdmin version but works in older version
