Statement is 250 times slower than usual - postgresql

Question

I am running a series of very long statements, moving a lot of data. The statement in question looks like something along the lines of this:
CREATE TABLE a (...);
WITH cte_1 AS (...),
cte_2 AS (...)
INSERT INTO a (...)
SELECT ....
This creates the table and populates it with roughly 60 000 large rows. Usually it was taking around 1 second to perform this statement. "Usually" means that the exact same environment (all tables and data are created by a script - no manual interaction, so all instances of the same environment are identical when it comes to data and data structure) but on a different machine, takes just 1 second to execute this.
But on a new machine that I have, this statement suddenly takes 4.5 minutes to complete. During that time Postgresql takes up 100% of a CPU core. During that time, if I open up a new connection, say, with DBeaver, and run the exact same query, with a single change (creating table b instead, and inserting there, from the exact same data sources), it takes 0.8 seconds to complete, during the time that the first query is running.
So it's definitely not the script, but rather something about the inner workings of Postgresql, or its config. Which is why I'm sharing it, instead of the code.
Oh, and this query:
SELECT
pid, datname, usename,
application_name, query, state,
to_char(current_timestamp - query_start, 'HH24:MI:SS') AS running_for
FROM pg_stat_activity;
outputs 2 DBeaver processes (SHOW search_path which is idle, and the query above), and the slow query:
9736 my_db my_user psql active 00:02:42
Out of hundreds of statements, in various schemas, with various complexity, this is the only one affected. The only thing that was modified that made it slow, is the new OS (Ubuntu 17.04), with probably this new config, since the old one was lost because my mac died.
data_directory = '/var/lib/postgresql/9.6/main'
hba_file = '/etc/postgresql/9.6/main/pg_hba.conf'
ident_file = '/etc/postgresql/9.6/main/pg_ident.conf'
external_pid_file = '/var/run/postgresql/9.6-main.pid'
listen_addresses = '*'
port = 5432
max_connections = 40
unix_socket_directories = '/var/run/postgresql'
shared_buffers = 4GB
temp_buffers = 2GB
work_mem = 512MB
maintenance_work_mem = 2GB
dynamic_shared_memory_type = posix
wal_level = minimal
fsync = off
synchronous_commit = off
full_page_writes = off
wal_buffers = 16MB
max_wal_size = 4GB
checkpoint_completion_target = 0.9
seq_page_cost = 1.0
random_page_cost = 1.5
effective_cache_size = 12GB
default_statistics_target = 500
logging_collector = on
log_directory = 'pg_log'
log_filename = 'query.log'
log_min_duration_statement = 0
debug_print_parse = off
debug_print_rewritten = off
debug_print_plan = off
debug_pretty_print = on
log_checkpoints = off
log_connections = off
log_disconnections = off
session_preload_libraries = 'auto_explain'
auto_explain.log_min_duration = '2s'
auto_explain.log_nested_statements = true
auto_explain.log_verbose = true
autovacuum = on
autovacuum_max_workers = 1
datestyle = 'iso, mdy'
timezone = 'UTC'
lc_messages = 'C'
lc_monetary = 'C'
lc_numeric = 'C'
lc_time = 'C'
default_text_search_config = 'pg_catalog.english'
max_locks_per_transaction = 2048
shared_preload_libraries = 'cstore_fdw'
Per request, this is an old backup that I had, of another config, where I manually adjusted just 1 item (shared_buffers), and the rest is pretty much default.
Update
Skipped old config
I replaced the config with the old one, and still got the same issue, except now everything was slower.
Notable update
Query became lightning fast again when I added
ANALYZE source_table1;
ANALYZE source_table2;
ANALYZE source_table3;
on the largest tables that were queried, before running the query. I didn't have to do this before and it worked perfectly fine.

Answer 1

This is one scenario which could explain the behaviour which you are seeing. This assumes that the source_table{1,2,3} are rebuild straight before the query is computed (as it would happen when it is part of an ETL):
Before:
source tables for the query are created
autovacuum has time to do a ANALYZE on the table while some other process finishes
postgres chooses the correct plan on the query
If now the data or the ETL changes a bit and this results in postgres having no time for autovacuum before the query, then statistics are off and the query execution time explodes.