Opened 3 weeks ago

Closed 10 days ago

#37130 closed Cleanup/optimization (fixed)

Unnecessary query in db cache backend when CULL_FREQUENCY > MAX_ENTRIES + 1

Reported by: Jacob Walls Owned by: Vishy
Component: Core (Cache system) Version: dev
Severity: Normal Keywords:
Cc: Mike Lissner Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: no

Description

The db cache backend deletes expired entries according to a CULL_FREQUENCY denominator after expired entries are deleted. For example: 2, means delete 50%. This generates SQL like:

SELECT cache_key from ... ORDER_BY cache_key LIMIT 1 OFFSET N
DELETE FROM ... WHERE cache_key < result of query 1

But where N is 0 (cull_num in the code), the SELECT is unnecessary. I'm suggesting there should be another fast path where cull_num is 0 that simply exits.

I spotted this in a real user's logs, see #32785.

This would happen when CULL_FREQUENCY > MAX_ENTRIES + 1. I imagine the use cases for that configuration would be:

  • a culling strategy that is age-based instead of random, see ​forum
  • in tests, overriding MAX_ENTRIES to 0 or 1 for determinism, which would then fall below the default CULL_FREQUENCY of 3.

Change History (7)

comment:1 by Vishy, 3 weeks ago

Owner: set to Vishy
Status: new → assigned

comment:2 by Sarah Boyce, 3 weeks ago

Triage Stage: Unreviewed → Accepted

Thank you!

comment:3 by Vishy, 12 days ago

Has patch: set

comment:4 by Jacob Walls, 11 days ago

Patch needs improvement: set

comment:5 by Vishy, 10 days ago

Patch needs improvement: unset

comment:6 by Jacob Walls, 10 days ago

Triage Stage: Accepted → Ready for checkin

comment:7 by Jacob Walls <jacobtylerwalls@…>, 10 days ago

Resolution: → fixed
Status: assigned → closed

In 867c7c0:

Fixed #37130 -- Skipped DB cache deletion when culling offset is zero.

Note: See TracTickets for help on using tickets.
Back to Top