Postgresql select max performance
if you look at the statistics the execution plans make perfect sense. 
The table has around 840k tuples almost all of table id 3. 
So if you're looking for max(timecode) scanning the timecode index backwards makes perfect sense with table id 3 (almost every line you hit has that id). 

But if you're looking for table id 1 - you have only 120 tuples out of 840k, your best bet is to scan these 120 tuples looking for the  max(timecode). 

It's like looking for a needle in a hay stack - looking for hay is simpler than looking for the needle. 

Hope it made some sense into what the optimizer planned. 

Btw, you could try to build a composite index of table id and timecode - I'm not near a db to check but I think PG could use that to skip to the max timecode per table id directly. 
- worth a shot :)

Regards 
Jony