Timeline for SQL estimates are way off on DELETE statement with Triggers on huge tables
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 17, 2020 at 17:31 | vote | accept | Danielle Paquette-Harvey | ||
| Mar 17, 2020 at 17:31 | |||||
| Mar 17, 2020 at 15:59 | history | edited | David Browne - Microsoft | CC BY-SA 4.0 |
added 493 characters in body
|
| Mar 17, 2020 at 15:52 | comment | added | David Browne - Microsoft | That's fine. But each FK link needs to be properly indexed. And it's "parent-child" type relationships that benefit the most from having the parent table FK as the leading columns in the child table clustered PK. But the multi-hop nature of this will make estimation hard, and you'll probably have perform the deletes from the bottom-up. | |
| Mar 17, 2020 at 15:43 | comment | added | Danielle Paquette-Harvey | The EventConditions table is not related by TripId. It is related to the "Events" table by EventId, which is related to the Segments table by "SegmentId" which is related to the Trips table by TripId. It's a sort of parent-child relation. | |
| Mar 17, 2020 at 15:30 | history | edited | David Browne - Microsoft | CC BY-SA 4.0 |
edited body
|
| Mar 17, 2020 at 15:23 | history | answered | David Browne - Microsoft | CC BY-SA 4.0 |