Actual count was 54. This was a baseball database. View is a "game situation" view. https://github.com/praphael/baseball/blob/main/retrosheet_init_db.py#L127

Actual count was 54. This was a baseball database. View is a "game situation" view. https://github.com/praphael/baseball/blob/main/retrosheet_init_db.py#L1274 https://github.com/praphael/baseball/blob/main/retrosheet_in... The real killer wasn't actually with this view. It was the fact it was joining with game_info_view, which itself had about 15 joins. game_info_view is what I ended up materializing. Speed was then reasonable (under 1 s) with just this step. I was trying to do everything in totally in memory (which was possible when it was just the gamelogs) so was really trying to minimize space, which required denormalization. Altogether the DB prior to the " denormalization" was about 3 GB for the entire history of Major League Baseball :-). The Retrosheet files however were < 1 GB uncompressed (about 250 MB compressed) and that. "Materializing" the game_info_view added another 1 GB, so 4 GB total. So the DB even with its supposedly "efficient" storage was expanding the plain-text storage by a factor of 3-4.