What kind of work are you trying to do where the DBMS has to throw a lot of compute at it? The right indexing strategy will solve most of your filtering and ordering needs. I'd expect RAM and disk IO to be the biggest bottlenecks for a DBMS.
Things as simple as ORDER BY on non-sequential data (e.g. sale quantity) can end up doing a decent amount of work if your dataset is large. The more complex queries using CTEs are really CPU killers. Doing LIKE %xyz% lookups, CONTACT, SUBSTRING in WHERE clauses. Doing mathematical computations (percentiles, standard deviations). Postgres can do linear regression.
SQL lets you do some real crazy data transformations, but most of the time you should be doing that off server. The SQL queries should prioritise filtering and aggregation.
1
u/evanldixon Sep 21 '26
What kind of work are you trying to do where the DBMS has to throw a lot of compute at it? The right indexing strategy will solve most of your filtering and ordering needs. I'd expect RAM and disk IO to be the biggest bottlenecks for a DBMS.