Aquinus
Resident Wat-man
- Joined
- Jan 28, 2012
- Messages
- 13,147 (2.94/day)
- Location
- Concord, NH, USA
| System Name | Apollo |
|---|---|
| Processor | Intel Core i9 9880H |
| Motherboard | Some proprietary Apple thing. |
| Memory | 64GB DDR4-2667 |
| Video Card(s) | AMD Radeon Pro 5600M, 8GB HBM2 |
| Storage | 1TB Apple NVMe, 4TB External |
| Display(s) | Laptop @ 3072x1920 + 2x LG 5k Ultrafine TB3 displays |
| Case | MacBook Pro (16", 2019) |
| Audio Device(s) | AirPods Pro, Sennheiser HD 380s w/ FIIO Alpen 2, or Logitech 2.1 Speakers |
| Power Supply | 96w Power Adapter |
| Mouse | Logitech MX Master 3 |
| Keyboard | Logitech G915, GL Clicky |
| Software | MacOS 12.1 |
I would use the LEFT JOIN version that Biggie wrote 2 posts ago. Sub-queries can have performance penalties if there are enough nested loops generated by the query planner. It's been quite some time since I've used MySQL but PostgreSQL will let you add "EXPLAIN ANALYZE" to the beginning of any SELECT query and it will describe how the query planning is going to attack doing the query.
Without seeing anything like that, it looks like that an index on staff_cpd.staffid and an index on staff_cpd.cpdid (if not already a primary key) might speed up the query.
Also next time you ask a SQL question, try to include some schema so we know what we're querying.
Without seeing anything like that, it looks like that an index on staff_cpd.staffid and an index on staff_cpd.cpdid (if not already a primary key) might speed up the query.
Also next time you ask a SQL question, try to include some schema so we know what we're querying.
