> -> Nested Loop (cost=0.00..176144.30 rows=57925 width=26) > (actual time=68.322..529472.026 rows=57925 loops=1) > -> Seq Scan on ticketing_codes_played > (cost=0.00..863.25 rows=57925 width=8) (actual time=0.042..473.881 > rows=57925 loops=1) > -> Index Scan using ticketing_codes_pk on > ticketing_codes (cost=0.00..3.01 rows=1 width=18) (actual > time=9.102..9.108 rows=1 loops=57925) > Index Cond: (ticketing_codes.code_id = > "outer".code_id) > Total runtime: 542000.093 ms > (27 rows) > > > I'll be more than happy to provide any additional information > that I may > be able to gather. I'd be most happy if someone would scream something > like "four joins, smells like a poor design" because design > is poor, but > the system is in production, and I have to bare with it. It looks like that nested loop which is joining ticketing_codes_played to ticketing_codes is the slow part. I'm curious how many rows are in the ticketing_codes table? Four or five joins does not seem like a lot to me, but it can be slow if you are joining big tables with other big tables.
