Why does query planning time increase on a standby replica with increase in dead tuples but not on the primary?

We are using Postgres 10 with standby replication (read replica in recovery mode). For the same query, we observe significantly higher planning time on the replica compared to the primary. Execution time remains similar. The query is like so

SELECT *  
FROM emp, sessions  
WHERE emp.id = ''  
  AND emp.active = 't'  
  AND sessions.emp_id = emp.id;

- sessions table: ~250M records - emp table: ~100M records - Both primary and replica are on similar VMs (same RAM, HDD, processor, freespace etc.). Observations: - High number of dead tuples for sessions table (~75k dead tuples added/day), that is constantly increasing. - As dead tuples increase, planning time on the replica grows, but it remains constant on the primary. - Running VACUUM (on primary) temporarily fixes the issue, normalizing planning time on the replica. [Cannot run VACUUM on replica as it's in readonly/recovery mode] - Running ANALYZE on the primary does not help. The statistics seem to be the same - Dead tuples are created frequently due to a maintenance job that deletes records from the sessions table every 10 seconds. We're working on fixing this. - Replication lag is minimal and doesn't appear to be a factor (the records are definitely present in replica) Action we've taken till now - running auto-vacuum more aggressively so that the dead tuple count does not get higher - DB maintenance job fix **Question still remains, why does the same number of dead tuples not affect the primary's planning time but impacts the replica's planning time?** **Primary**

QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop  (cost=1.26..17.30 rows=1 width=451) (actual time=0.054..0.055 rows=1 loops=1)
   Buffers: shared hit=11
   ->  Index Scan using emp_pkey on emp a  (cost=0.69..8.71 rows=1 width=138) (actual time=0.036..0.037 rows=1 loops=1)
         Index Cond: (id = '123456'::text)
         Filter: active
         Buffers: shared hit=6
   ->  Index Scan using sessions_pkey on sessions g  (cost=0.57..8.59 rows=1 width=313) (actual time=0.015..0.015 rows=1 loops=1)
         Index Cond: (id = a.id)
         Buffers: shared hit=5
 Planning time: 23.652 ms
 Execution time: 0.096 ms

**Replica**

QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop  (cost=1.26..17.30 rows=1 width=451) (actual time=0.062..0.064 rows=1 loops=1)
   Buffers: shared hit=11
   ->  Index Scan using emp_pkey on emp a  (cost=0.69..8.71 rows=1 width=138) (actual time=0.045..0.046 rows=1 loops=1)
         Index Cond: (id = '123456'::text)
         Filter: active
         Buffers: shared hit=6
   ->  Index Scan using sessions_pkey on sessions g  (cost=0.57..8.59 rows=1 width=313) (actual time=0.014..0.014 rows=1 loops=1)
         Index Cond: (id = a.id)
         Buffers: shared hit=5
 Planning time: 854.801 ms
 Execution time: 0.102 ms