docs: improve queueName docs to avoid high cardinality

[blimmer]

Description

We recently ran into an issue where our serverless database had to dramatically scale up capacity. Upon reviewing those queries, we realized that the issue was caused by Graphile Worker query:

with j as ( 
    select jobs.job_queue_id, jobs.priority, jobs.run_at, jobs.id 
    from graphile_worker . _private_jobs
 as jobs 
    where jobs.is_available = ? and run_at <= now ( ) and task_id = any ( ? :: int [ ] ) and ( jobs.job_queue_id is ? or jobs.job_queue_id in ( 
        select id 
        from graphile_worker . _private_job_queues
 as job_queues 
        where job_queues.is_available = ? for 
        update skip locked 
    ) ) 
order by priority asc, run_at asc 
limit ? for 
update skip locked 
), q as ( 
    update graphile_worker . _private_job_queues
 as job_queues 
    set locked_by = ? :: text, locked_at = now ( ) 
    from j 
    where job_queues.id = j.job_queue_id 
) 
update graphile_worker . _private_jobs
 as jobs 
set attempts = jobs.attempts + ?, locked_by = ? :: text, locked_at = now ( ) 
from j 
where jobs.id = j.id returning *

Specifically the subquery against the _private_job_queues table.

select id from graphile_worker._private_job_queues
  where job_queues.is_available = ?
  for update skip locked

We were creating lots of job queues using high-cardinality values (e.g., database row IDs), which caused many thousands of dead queues to build up in this table.

db=> select count(*) from graphile_worker._private_job_queues;
 count
-------
 61106
(1 row)

Because the graphql worker polling job necessarily does a table scan on _private_job_queues, this caused a big performance issue for us, forcing the DB to scale up.

When I reviewed the documentation, I found a warning about not using randomly-generated values in queueNames

worker/website/docs/admin-functions.md

Lines 127 to 140 in ae40946

	## Database cleanup
	Over time it's likely that graphile_worker's tables will grow with stale values
	for old job queue names, task identifiers, or permanently failed jobs. You can
	clean up this stale information with the cleanup function, indicating which
	cleanup operations you would like to undertake.
	:::tip
	If you find yourself calling this quite often or on a schedule, it's likely that
	you are doing something wrong (e.g. allowing jobs to permafail, using random
	values for job queue names, etc).
	:::

This was helpful. However, I think it makes sense to also warn about this on the queueName parameter itself, so people know before there's a problem. This PR adds those warnings.

Performance impact

N/A - docs only

Security impact

N/A - docs only

Checklist

• My code matches the project's code style and yarn lint:fix passes.
• N/A - docs only. I've added tests for the new feature, and yarn test passes.
• N/A - docs only. I have detailed the new feature in the relevant documentation.
• N/A - docs only. I have added this feature to 'Pending' in the RELEASE_NOTES.md file (if one exists).
• N/A - docs only. If this is a breaking change I've explained why.

[blimmer]

Feedback is welcome on the phrasing here - I don't feel strongly!

[benjie]

Thanks!

[benjie]

@jemgillam Please confirm this renders okay. If not, move it to below the list of options.

[jemgillam]

Seems fine

[benjie]

The lines are all spaced out?

[jemgillam]

Actually, I was only looking at the indentation of the list, not the line spacing between bullets. I have moved the warning outside of the list.