Inefficient filter order in query plan

I'd like to understand why PostgreSQL is choosing to filter on the most inefficient predicate first in the query below.

Version: PostgreSQL 9.3.2 on x86_64-unknown-linux-gnu, compiled by gcc (SUSE Linux) 4.7.1 20120723 [gcc-4_7-branch revision 189773], 64-bit
Hardware: 24 2.93GHz Xeon cores and 32GB RAM

Table in question:
------------------------------------------------------------
CREATE TABLE audit_trail (
   id int PRIMARY KEY NOT NULL,
   model varchar(128) NOT NULL,
   model_id int NOT NULL,
   created bool,
   updated bool,
   deleted bool,
   change_set text,
   created_by varchar(64) NOT NULL,
   created_date timestamp NOT NULL,
   updated_by varchar(64) NOT NULL,
   updated_date timestamp NOT NULL
);
CREATE UNIQUE INDEX audit_trail_pkey ON audit_trail(id);

Row count: 5,306,596
Min / Avg / Max character length of change_set column values: 11 / 165 / 12717859
Number of unique values in model column: 196

Query and plan:
------------------------------------------------------------
SET track_io_timing = on;
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM audit_trail WHERE model = 'User' AND model_id = 304 AND change_set ILIKE '%test%';

Seq Scan on audit_trail  (cost=0.00..243427.98 rows=1 width=189) (actual time=15509.722..17943.896 rows=6 loops=1)
  Filter: ((change_set ~~* '%test%'::text) AND ((model)::text = 'User'::text) AND (model_id = 304))
  Rows Removed by Filter: 5306590
  Buffers: shared hit=10410 read=164384
  I/O Timings: read=310.189
Total runtime: 17943.930 ms

Observations:
------------------------------------------------------------
1) Without the change_set predicate, the query runs in 1 second and returns 461 rows.
2) Turning statistics off for the change_set column has no effect on the plan or execution time:
      ALTER TABLE audit_trail ALTER COLUMN change_set SET STATISTICS 0;
      ANALYZE audit_trail(change_set);
3) Setting statistics to the max value has no effect on the plan or execution time:
      ALTER TABLE audit_trail ALTER COLUMN change_set SET STATISTICS 10000;
      ANALYZE audit_trail(change_set);
4) Adding an index on (model, model_id) changes the plan so that it starts with an index scan. Query time < 1s.
      CREATE INDEX audit_trail_model_idx ON audit_trail (model, model_id);

      Aggregate  (cost=12.29..12.30 rows=1 width=4) (actual time=1.455..1.456 rows=1 loops=1)
        ->  Index Scan using audit_trail_model_idx on audit_trail this_  (cost=0.56..12.29 rows=1 width=4) (actual time=1.446..1.446 rows=0 loops=1)
              Index Cond: (((model)::text = 'User'::text) AND (model_id = 304))
              Filter: (change_set ~~* '%test%'::text)
              Rows Removed by Filter: 461

Although adding the index will fix the performance problem, I'd like to understand why, in absence of the index, PostgreSQL would choose to filter on the change_set value first. Since it is not specified first in the predicate and its column ordinality is higher than model and model_id, the plan generator must be choosing it first for some particular reason.

Any insight is appreciated.