Repository navigation
Conversation
Since SQLite 3.54, sqlite3_clear_bindings() invalidates the query plan of the statement, so a statement was re-prepared on every run. Bind NULL only to the parameters that were not bound in this run instead, and skip clearing in the tag store, which always binds every parameter. Refs: nodejs#66800 Signed-off-by: dualfroz <me@dualfroz.com>
|
Review requested:
|
|
Welcome to Node.js, and thank you for your first contribution! Before review, please take a moment to read:
Please make sure every commit is signed off. For a first pull request, GitHub Actions require collaborator approval and Jenkins CI must be started by a collaborator or triager, so an initial wait is normal. Caution AgentScan found account activity patterns that may be consistent with automation. This is a heuristic, not proof that this pull request was opened by an agent or violates policy. AI-assisted contributions are permitted, but automated tooling must not open pull requests without advance approval, and contributors must personally understand, test, verify, and take responsibility for every submitted change. See the AgentScan analysis, AI use policy, and automation policy for additional context. |
BindParamscalledsqlite3_clear_bindings()before every run, which since SQLite 3.54 invalidates the plan, so JOIN queries got re-prepared each time. it now tracks which parameters were bound and binds NULL only to the rest, so omitted params are still NULL.ResetAndBindStatementalways binds every parameter, so it doesnt clear at all. added a test for omitted named params, including{ k, $k }hitting the same index.note this only removes the re-prepare for integer (BigInt) bindings. plain JS numbers go through
sqlite3_bind_double, which in 3.54 still invalidates the plan on every bind, so the case from the issue gets only a bit faster (3.4-4.9 to 3.1-3.2 us perget). BigInt goes from 3.4-4.3 to ~0.7 us.Refs: #66800