3 ms·
Can you clarify? I don't think I've ever seen such a cliff where the database is using the same query plan? There's sometimes small incremental slow downs as
by TristanBall 3y ago
Can you clarify?
I don't think I've ever seen such a cliff where the database is using the same query plan?
There's sometimes small incremental slow downs as you pass btree depth thresholds and have to add more, but tbh even that's not usually noticeable.
I have seen plenty of instances where the database decides an index is no longer the right access,but gets that wrong, and the result is terrible.. but I see that as a different issue.
- lmm 3y ago> There's sometimes small incremental slow downs as you pass btree depth thresholds and have to add more, but tbh even that's not usually noticeable. Even this kind of "narrow" slowdown can be substantial. Well, I don't know specifically that it's depth thresholds, but that kind of behaviour - the table passes a certain size and it's suddenly taking 30% longer to insert/read than it did when it was 2% smaller. > I have seen plenty of instances where the database decides an index is no longer the right access,but gets that wrong, and the result is terrible.. but I see that as a different issue. IMO it's the same issue, at least from the perspective of the poor chump on call.
- bcrosby95 3y ago> Even this kind of "narrow" slowdown can be substantial. Well, I don't know specifically that it's depth thresholds, but that kind of behaviour - the table passes a certain size and it's suddenly taking 30% longer to insert/read than it did when it was 2% smaller. This has usually been a memory problem for us - our hot dataset no longer fits in it.