This is a bump of the thread at https://pcpartpicker.com/forums/topic/305061-feature-suggestion-add-ppi-on-monitors. I would just reply to that one, but I seem unable to for some reason. I also think that adding a ppi filter would be a really nice feature to have. As someone mentioned in the comments, sure, you can look at individual monitors and calculate the ppi individually, but this gets really tedious really fast, and you can't use this method to filter the site to only show monitors with a ppi over a certain threshold. Resolution isn't really a good metric to use, because if your screen is too large for your high resolution, then it can still look worse than a smaller screen with lower resolution. Pixel density is really what matters.
I am guessing that the reason this is not currently a feature on the site right now is that resolution and screen size are the parameters being stored in the database, and storing ppi as a separate database column would be redundant and potentially lead to inaccuracies if resolution or screen size gets updated but ppi does not, or vise versa. However, if you do not store ppi in the database, then it cannot be indexed, so filtering for it would be slow, and certain CMFs like Django, for instance, cannot natively filter by method. See https://stackoverflow.com/questions/2276768/django-query-filtering-from-model-method.
So, the pcpartpicker developers have several options here, none of which is perfect:
Create a separate ppi column, which duplicates data and could lead to inaccuracies. These could be mitigated by having the column be marked as uneditable by humans and having the contents be generated automatically in the model's save method.
Filter for ppi by applying the ppi() method separately to each individual result after retrieving it from the database. This is very slow and intensive with a larger number of entries, so if the site has too many monitors or users, this might not be good, though caching results would be a good way to fix this.
Bypass the framework's filtering methods and write raw SQL for this job, which would then allow the calculation to be done in the database instead of by the site's code. This might be faster than option 2, but it is also a very bad way to go about it because you are bypassing the models entirely, which can lead to bugs down the line if the models or database structure change. On top of that, this method still has the problem of ppi not being indexed, so it won't be as fast as option 1.
Don't allow filtering by ppi.
Personally, I'd go with option 2, unless it increases the load on the servers too much, in which case I'd do option 1. I'd pick 4 over 3 though.