Thanks so much for the quick reply and suggestions.
I felt a bit like it might be postgres when I looked in there and ran a direct "select * from tourney_hand_summary" directly in pgadmin and that takes 115 seconds for 370-380K records with no joins at all (but didn't stress my system at all).
My PT4 heatmaps are just the stock standard ones right now to look at my RFI, or VPIP, etc from each position. And I have very few added stats (I think just one), I'll investigate them still. These do seem to take more than 4 minutes without any sort of filter other than by position. I only have about 4 reports right now, too. But have been looking at making more for my students, that's what got me investigating.
This might be normal timing, but I thought I should check I could make more things just live in cache, or just somehow use more of my resources that are available (it's not stressing my system at the slightest). Happy to put in a report if you think it's outside of the normal.
Thanks again!
Flag_Hippo wrote:I don't have any specific tweaks for you without but if you have a number of custom statistics that are using the
database cache then there shouldn't be any significant delays. If that's the case you can report your issue to us with your log file so we can see what's going on and follow up with you:
Tutorial: Reporting A ProblemBear in mind that PostgreSQL has a limit of 1,600 columns in a table so if you have a number of custom heat maps it's possible you might have exceeded this limit as each individual heat map requires hundreds of columns and if you have custom statistics that are not using the database cache then they would need to be calculated on the fly and there will likely be delays as a result.