Database extremely slow after creating custom stats

[Flag_Hippo]

Have questions about the custom stats + columns which i created. They are still exist in "cash player stats" . Is there a problem with them being there?

That shouldn't cause a problem.

If add some of them in HUD in Profile or Popup Group is it possible my new Database to be damaged again?

I don't see how that would be possible. A database can get damaged when an intensive process like a full cache rebuild gets forcibly shutdown while database connections are active.

If delete all my created custom columns and all created custom stats, can i import the same stats again (i have them exported) ?

You can do that although there wouldn't be a point to that if those stats and columns are already there.

Thought, if uninstall PT4 and PostgreSQL i will have to register again Pt4 with code and will be completely new, and just to make these created custom stats and columns to disappear,

That's not going to change anything regarding the stats and columns.

then i can import these custom stats exported, without columns..

I am not sure what you mean with this. Stats will not function without columns. If you have exported a stat it will include the necessary columns and when imported the columns get imported too.

[fthat]

I had the exact same issue.
After adding just a couple of custom stats (very basic ones from the PT website), my import rates decreased by over 95%.

After messing around with my database server & settings, following all the guides (cache rebuild, index rebuild etc.) multiple times, the issue still persisted.

Looking at the database schema and data itself, I didn't spot anything particularly unusual. Also there is basically zero documentation about the database and overall backend procedures available. At least I couldn't find anything useful.

In the end I was left with two options:
1) Setup a monitoring tool for my postgres server and trying to find the bottleneck myself. My best guess at the time was some issues with indicies or inefficient/complex queries caused by the custom stats.
2) Just create a new database and hope for the best.

I figured that even if I would find the root cause, there would be little chance for me to fix the issue myself and waiting months for a possible fix to be released wasn't an option.

I went with option #2, created a fresh DB and reimported all my hands at full speed in a fraction of the time it took me to try fixing the old one.

I'm sorry if this isn't a solution at all.
Trying to reverse engineer the problem, spending time to open a proper ticket with all the stuff I found, just to hope for the developers to pick it up and release a fix somewhere in 2026, if ever, didn't made sense to me in the end.
I know how hard it is to maintain a legacy codebase with all its quirks and problems and yet I would wish for a better documentation and/or tighter release cycles for a software we pay for on a yearly basis.