Re: Planning time is high in Postgres 11.5 Compared with Postgres 10.11

avinash varma <avinashvarma443(at)gmail(dot)com> writes:
> Perf Report Output:
> Samples: 41K of event 'cpu-clock:uhH', Event count (approx.): 10461000000
> Children Self Command Shared Object Symbol
> *+ 49.97% 49.97% postgres postgres [.]
> FunctionCall2Coll+ 17.58% 17.58% postgres postgres [.]
> int8eq+ 15.15% 15.15% postgres postgres [.] eqjoinsel+
> 12.82% 12.82% postgres postgres [.]
> eqjoinsel_semi.isra.17*
> + 1.82% 1.82% postgres postgres [.] pglz_decompress
> + 0.96% 0.00% postgres [unknown] [.] 0000000000000000
> + 0.62% 0.00% postgres [unknown] [.]
> 0x0000000000000010
> 0.56% 0.56% postgres postgres [.] deconstruct_array
> 0.20% 0.00% postgres [unknown] [.]
> 0x0000000001674bd0

Hm. eqjoinsel didn't change at all between v10 and v11. Are you
*sure* those installations have the same configurations? A plausible
theory is that one has got a much larger default_statistics_target
than the other (or at least, did when these tables were last analyzed),
and in consequence these tables have large most-common-values
statistics arrays, but not in the v10 installation.

[ thinks for a bit ] It seems possible that you could end up here
even if the user-level settings are indeed the same, as a result of

https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=b5db1d93d

which changed the method for deciding which values are MCVs. Maybe
these tables have some corner-case distribution that causes the new
method to think there are many more MCVs than the old one thought.

First thing to do is to look into pg_stats and see how large those
arrays actually are in each case ...

regards, tom lane