Open ugavnholt opened 3 months ago
Hi @ugavnholt, please add branch-* labels to identify which branch(es) this C-bug affects.
:owl: Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.
Hello, I am Blathers. I am here to help you get the issue triaged.
Hoot - a bug! Though bugs are the bane of my existence, rest assured the wretched thing will get the best of care here.
I was unable to automatically find someone to ping.
If we have not gotten back to your issue within a few business days, you can try the following:
:owl: Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.
This a known limitation that needs the documentation to be updated, which can be worked around with a smaller batch size.
@fqazi thank you for the answer, my own testing did reveal that smaller batch sizes worked. It seems like behind the scenes that the ttl batch delete is using one huge parameterized statement, and the number of parameters for that is limited. Some feedback about the ttl mechanics, is that there seem to be an opportunity for optimization here to handle big tables.
Describe the problem
Having a big table with billions rows, makes ttl jobs fail with lexical error: placeholder index must be between 1 and 65536"
Having a big table with billion of rows, where thousands of records are being added every second, TTL fails to process the table.
To Reproduce
Fill the table with >1b rows, and add ~2k rows every second, and watch the ttl cleanup log.
Expected behavior Expects the TTL job to run, where TTL select loads the oldest 5.000.000 rows at each interval, deleting all selected records at batches of 50.000
Environment:
Additional context Lowering the intervals/batch sizes make the select statement take unproportional resources from the cluster, raising the interval/batch sizes causes this error - hence using TTL to trim a big table seems broken.
Jira issue: CRDB-41739