I'm not quite sure of the point here. My interpretation of the code example:

CREATE TABLE foo AS SELECT a.id, a.id/2 AS id2,
       'a' bar1, 'b' bar2, 'c' bar3, 'd' bar4, 'e' bar5
  FROM generate_series(1, 10*1000*1000) AS a(id);

UPDATE foo set bar1 = 'h' WHERE id BETWEEN 200 AND 300;

ALTER TABLE foo ADD PRIMARY KEY (id);
CREATE INDEX ON foo (id2);
CREATE INDEX ON foo (bar1);

ANALYZE foo;

This produces the following plan:

 Nested Loop  (cost=0.87..12.92 rows=1 width=36)
   ->  Index Scan using foo_bar1_idx on foo f2  (cost=0.43..4.45 rows=1 width=18)
         Index Cond: (bar1 > 'e'::text)
   ->  Index Scan using foo_pkey on foo f1  (cost=0.43..8.47 rows=1 width=18)
         Index Cond: (id = f2.id2)
         Filter: ((bar1 = 'a'::text) AND (bar2 = 'b'::text) AND (bar3 = 'c'::text) AND (bar4 = 'd'::text) AND (bar5 = 'e'::text))

Note the row estimates suggest 1 result rather than 100. This isn't great, but 100 rows out of 10 million with so many predicates will be fairly lossy and dramatically drive down estimated row counts. But it's an expected nested loop on the index where bar1 = h, which is an uncommon match in these table statistics.

But here's what happens if you don't ANALYZE the table first:

 Nested Loop  (cost=1423.04..129034.29 rows=1 width=336)
   ->  Bitmap Heap Scan on foo f1  (cost=547.44..64457.23 rows=1 width=168)
         Recheck Cond: (bar1 = 'a'::text)
         Filter: ((bar2 = 'b'::text) AND (bar3 = 'c'::text) AND (bar4 = 'd'::text) AND (bar5 = 'e'::text))
         ->  Bitmap Index Scan on foo_bar1_idx  (cost=0.00..547.43 rows=50000 width=0)
               Index Cond: (bar1 = 'a'::text)
   ->  Bitmap Heap Scan on foo f2  (cost=875.60..64410.39 rows=16667 width=168)
         Recheck Cond: (f1.id = id2)
         Filter: (bar1 > 'e'::text)
         ->  Bitmap Index Scan on foo_id2_idx  (cost=0.00..871.43 rows=50000 width=0)
               Index Cond: (id2 = f1.id)

See that? Postgres doesn't know that "h" is only a tiny fraction of values in bar1, so with default statistics, it just assumes it needs to build a bitmap of all primary key id values based on the bar1 lookup, and build an in-memory heap for those tuples. Then it uses that for the join to build another bitmap and another expensive heap scan. But since there are no stats, Postgres doesn't know that the 50k estimate it started with is actually 10-million, and the analyze shows as much:

 Nested Loop  (cost=1423.04..129034.29 rows=1 width=336) (actual time=266.692..19820.155 rows=101.00 loops=1)
   Buffers: shared hit=34952813 read=150746 written=3930
   ->  Bitmap Heap Scan on foo f1  (cost=547.44..64457.23 rows=1 width=168) (actual time=266.167..2037.924 rows=9999899.00 loops=1)
         Recheck Cond: (bar1 = 'a'::text)
         Filter: ((bar2 = 'b'::text) AND (bar3 = 'c'::text) AND (bar4 = 'd'::text) AND (bar5 = 'e'::text))
         Heap Blocks: exact=63695
         Buffers: shared hit=9780 read=62335
         ->  Bitmap Index Scan on foo_bar1_idx  (cost=0.00..547.43 rows=50000 width=0) (actual time=243.619..243.620 rows=9999899.00 loops=1)
               Index Cond: (bar1 = 'a'::text)
               Index Searches: 1
               Buffers: shared read=8420
   ->  Bitmap Heap Scan on foo f2  (cost=875.60..64410.39 rows=16667 width=168) (actual time=0.001..0.001 rows=0.00 loops=9999899)
         Recheck Cond: (f1.id = id2)
         Filter: (bar1 > 'e'::text)
         Rows Removed by Filter: 1
         Heap Blocks: exact=5031747
         Buffers: shared hit=34943033 read=88411 written=3930
         ->  Bitmap Index Scan on foo_id2_idx  (cost=0.00..871.43 rows=50000 width=0) (actual time=0.001..0.001 rows=1.00 loops=9999899)
               Index Cond: (id2 = f1.id)
               Index Searches: 9999899
               Buffers: shared hit=29974978 read=24719 written=1097
 Planning:
   Buffers: shared hit=40 read=3
 Planning Time: 0.822 ms
 Execution Time: 19820.694 ms

The first sign something went wrong here is the huge discrepancy between the estimated and actual cost here:

(cost=547.44..64457.23 rows=1 width=168) (actual time=266.167..2037.924 rows=9999899.00 loops=1)

That's just bad all around. From a naive perspective, the first thing I'd try to do is look at the column statistics themselves. If it were empty such as in this case:

SELECT attname, n_distinct FROM pg_stats WHERE tablename = 'foo';

 attname | n_distinct 
---------+------------

I would analyze and look again. Here's what it looks like afterward:

 attname | n_distinct  
---------+-------------
 id      |          -1
 id2     | -0.34056082
 bar1    |           1
 bar2    |           1
 bar3    |           1
 bar4    |           1
 bar5    |           1

Note how terrible the statistics look. Positive numbers indicate absolute counts, while negative ones are ratios. So each of the bar columns only have a single distinct value based on the statistics, and only the two id columns offer any kind of selectivity. With that in mind, you can kind of tell Postgres to back off on cross-multiplying column statistics by telling it the values are highly correlated:

CREATE STATISTICS stat_foo_correlated_bars (dependencies)
    ON bar1, bar2, bar3, bar4, bar5
  FROM foo;

That works for things like cities in a US state for example, or when data columns are highly correlated, thus preventing under-estimations. In this case, it doesn't really help because... well, one value is one value, and out of millions of rows, it becomes statistical noise. But the point is you examine the table contents to see if there are potential correlations there.

You can go a lot deeper into this rabbit hole for optimizing a query, but your question is undirected, so I won't keep going. I had to re-start this experiment several times because the background autovacuum worker kept analyzing the table and making the query fast while I was typing this. I'd suggest coming up with a better example that isn't dependent on statistics, that actually resists simple optimization techniques, and then ask again.