Big jump in search time for Postgres Index query for results with high selectivity
As I understand your question you are asking why highly selective index scans might be much slower after a certain number of records are returned or after the table reaches a certain size.  As it turns out your query plans provide most of the information needed.  Understanding of course is the first step in trying to figure out how to solve the problem.  It looks to me like your slow query is hitting a much more heavily used db than the fast query.

As I look at your query plans, I see two immediate pieces of bad news.

The first piece of bad news is in the buffer usage. Your rows returned are less than double, but you hit about six times the number of buffer pages.  This is bad news because it means that PostgreSQL, following the index scan, is scanning through at least six times more information to find the rows to retrieve.  Significantly worse, you shift from the rarely used db of mostly read buffers (fast, but few db-specific services) to shared buffers which require more overhead.

The second piece of bad news is that the recheck condition in the slow query weeds out about three times as many records as are returned.  This tells me you need to vacuum and/or reindex this table.

I would recommend vacuum analyze and reindex first, followed if necessary by slightly lowering the shared buffer settings and see if this improves performance.