I know you wrote this before covering indexes came out, but I think they might be worth a mention.

Great idea, but my estimate was off by a much too significant amount using this function - about 31000 rows total, with the estimate returning about 20000, despite recently running an ANALYZE on the table (and not persisting any rows in the meantime).

"If you have a secondary index on the PK field, it will be able to perform less IO to perform a count." Stop spreading unsubstantiated claims without backing them up. See this post, and this post. I've yet to find a single source backing up your claim.

Approaching it from a purely empirical perspective in Postgres, I noticed that when I (accidentally) created an index on the columns that were already my primary key (same columns, same order), Postgres actually gave a slightly higher cost without the extra index (through EXPLAIN). Of course, that is just one database, plus the cost difference was less than a percent.

while this is certainly a handy tip for MySQL, not all databases treat booleans as integers (like Postgres for example).

agreed. just want to add as well, if you're using an ORM like Hibernate it'll likely be an extra big PITA since ENUM isn't a standard SQL datatype