First run of planner very slow on massively partitioned PostgreSQL 9.6 table
PostgreSQL holds lot of catalog attributes in session based system cache. When query uses lot of partitions (more than 100), then first plannning requires lot of reading operations. And it can be too slow. 

The number of partitions should not be bigger than 100. If you have more, then you can see some artefacts. 

In your case, the connection pooling can be solution. Try to install pgbouncer.