BUG #16905: Dropping and recreating a large table with 5 indexes slowed down query performance

The following bug has been logged on the website:

Bug reference: 16905
Logged by: tejas chavan
Email address: tejaschavanr10(at)gmail(dot)com
PostgreSQL version: 10.15
Operating system: Ubuntu 10.15-0ubuntu0.18.04.1
Description:

Hi,

We performed a data purging activity as the database server space was almost
full and needed to free up some space.
Table stats:
table size: 580 GB
Number of Indexes: 5
Indexes:
1. btree (col_a, col_b)
2. btree (col_a, col_c)
3. EXCLUDE USING gist (col_a WITH =, col_c WITH =, col_d WITH =,
tstzrange(col_e, col_f, ‘[)’::text) WITH &&) WHERE (col_d IS NOT NULL)
4. EXCLUDE USING gist (col_a WITH =, col_c WITH =, col_g WITH =, col_h WITH
=, tstzrange(col_e, col_f, ‘[)’::text) WITH &&) WHERE (col_g IS NOT NULL AND
col_h IS NOT NULL)
5. EXCLUDE USING gist (col_a WITH =, col_c WITH =, tstzrange(col_e, col_f,
‘[)’::text) WITH &&) WHERE (col_d IS NULL AND col_g IS NULL AND col_h IS
NULL)

Total index size: 1.2 TB

The steps performed are as below:
- Renamed the original table as _bkp
- Dropped indexes and constraints on the backup table
- Created the original table along with indexes with the same index name as
before

Post performing this activity, the queries which where performing well
before are running very slow.
After re-creating the table, for next 2 days, the performance of the query
was same as before (i.e. 20 minutes) but later it's taking more than 1 hour
to run.

After analyzing the query plan, it is observed when I am filtering based on
col_a and col_b, the query planner is scanning a composite index having
col_a and col_c. However I also have composite index of col_a and col_b. But
query planner is not picking it.

[Note: There are no other changes in the database structure apart from the
mentioned ones]

Kindly assist in tracking the root cause of the scenario and suggest the
approaches to improve the performance of the query.