Using regexp from table has unpredictable poor performance

I have items that need to be categorized by user defined matching rules. Trusted users can create rules that include regular expressions. I've reduced the problem to this example.

               Table "public.items"
 Column │  Type   │ Collation │ Nullable │ Default
────────┼─────────┼───────────┼──────────┼─────────
 id     │ integer │           │ not null │
 name   │ text    │           │ not null │
Indexes:
    "items_pkey" PRIMARY KEY, btree (id)

              Table "public.matching_rules"
    Column    │  Type   │ Collation │ Nullable │ Default
──────────────┼─────────┼───────────┼──────────┼─────────
 id           │ integer │           │ not null │
 name_matches │ text    │           │ not null │
Indexes:
    "matching_rules_pkey" PRIMARY KEY, btree (id)

I use the following query to find matches:

select r.id, i.id
from items i
  join matching_rules r on i.name ~ r.name_matches;

When there are few rules the query runs quickly. But as the number of rules increases the runtime often increases at a greater than linear rate.

For example if I run two queries, one the tests rule IDs 0 - 30 and another that tests 30 - 60 the total runtime is less than 100ms. But if I instead test rule IDs 0 - 60 in a single query the runtime balloons to over 1300ms.

explain analyze
select r.id, i.id
from items i
  join matching_rules r on i.name ~ r.name_matches
where r.id >= 0 and r.id < 30
;
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 Nested Loop  (cost=0.00..260.82 rows=80 width=8) (actual time=0.820..28.334 rows=172 loops=1)
   Join Filter: (i.name ~ r.name_matches)
   Rows Removed by Join Filter: 16828
   ->  Seq Scan on items i  (cost=0.00..18.00 rows=1000 width=27) (actual time=0.006..0.176 rows=1000 loops=1)
   ->  Materialize  (cost=0.00..2.86 rows=16 width=26) (actual time=0.000..0.001 rows=17 loops=1000)
         ->  Seq Scan on matching_rules r  (cost=0.00..2.78 rows=16 width=26) (actual time=0.004..0.012 rows=17 loops=1)
               Filter: ((id >= 0) AND (id < 30))
               Rows Removed by Filter: 35
 Planning Time: 0.086 ms
 Execution Time: 28.364 ms


explain analyze
select r.id, i.id
from items i
  join matching_rules r on i.name ~ r.name_matches
where r.id >= 30 and r.id < 60
;
                                                       QUERY PLAN
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 Nested Loop  (cost=0.00..470.86 rows=150 width=8) (actual time=1.418..65.508 rows=530 loops=1)
   Join Filter: (i.name ~ r.name_matches)
   Rows Removed by Join Filter: 28470
   ->  Seq Scan on items i  (cost=0.00..18.00 rows=1000 width=27) (actual time=0.007..0.193 rows=1000 loops=1)
   ->  Materialize  (cost=0.00..2.93 rows=30 width=26) (actual time=0.000..0.002 rows=29 loops=1000)
         ->  Seq Scan on matching_rules r  (cost=0.00..2.78 rows=30 width=26) (actual time=0.005..0.020 rows=29 loops=1)
               Filter: ((id >= 30) AND (id < 60))
               Rows Removed by Filter: 23
 Planning Time: 0.076 ms
 Execution Time: 65.573 ms


explain analyze
select r.id, i.id
from items i
  join matching_rules r on i.name ~ r.name_matches
where r.id >= 0 and r.id < 60
;
                                                       QUERY PLAN
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 Nested Loop  (cost=0.00..710.89 rows=230 width=8) (actual time=3.731..1344.834 rows=702 loops=1)
   Join Filter: (i.name ~ r.name_matches)
   Rows Removed by Join Filter: 45298
   ->  Seq Scan on items i  (cost=0.00..18.00 rows=1000 width=27) (actual time=0.006..0.442 rows=1000 loops=1)
   ->  Materialize  (cost=0.00..3.01 rows=46 width=26) (actual time=0.000..0.004 rows=46 loops=1000)
         ->  Seq Scan on matching_rules r  (cost=0.00..2.78 rows=46 width=26) (actual time=0.004..0.019 rows=46 loops=1)
               Filter: ((id >= 0) AND (id < 60))
               Rows Removed by Filter: 6
 Planning Time: 0.084 ms
 Execution Time: 1344.967 ms

It's also not predictable when additional regexp rows will trigger the poor performance. There's not a specific number of rows or kind of regexp that I can discern that triggers the issue. The regexps themselves are pretty trivial too. Only normal text, start and end of string anchors, and alternation.

I've vacuumed, analyzed, and I am on PostgreSQL 13.4 on x86_64-apple-darwin20.4.0, compiled by Apple clang version 12.0.5 (clang-1205.0.22.9), 64-bit.

Any ideas what's causing this?

Thanks.

Jack