Read data with group by 100000 distinct values on 36 million rows
Shrink datatypes --


INT takes 4 bytes; probably overkill for your data.
It is usually ill-advised to split a DATE into multiple columns.
Normalize any repeated VARCHARs.


You have nothing limiting the number of rows you need to look at, so the query must read the entire table.  Unless you have magical disks, you must have enough RAM to hold the entire table, do you?

Since you have nested GROUP BYs, there will need to be one or two temp tables, each with lots of rows, plus one or two sorts.

Your only hope to avoid "sub-par" performance by any database engine is to reformulate your query.

Since you are grouping by month, are the previous month's data static?  That is, could you summarize each month at the beginning of the next month, then use the Summary table?

It might be better to summarize daily, thereby avoiding the moderately large monthly query.

Such a summary table would probably look very much like the output of the derived table (in the from cause).  Probably this would be best:  PRIMARY KEY(p_s, bd, month, si).

Bug?  You are grouping by month.  Does that mean you are combining last July with this July?  Or did you mean to include year in that?  At which point, it is even more compelling to use DATE instead of two columns.