A partial index is used only when the planner can show that the query's WHERE implies the index predicate. The docs say the matching happens at planning time, not at run time, so a clause like status = $1 never implies status = 'queued' for every value the parameter could take.
The index sits on a job queue. CREATE INDEX jobs_queued ON jobs (id) WHERE status = 'queued'. From Go, db.QueryContext(ctx, q, "queued") with status = $1 in the text returns the same rows as the literal version. What can differ is the plan.
Prepared statements make it less predictable than that one sentence suggests. If the driver prepares the statement and reuses it, and plan_cache_mode is auto, the first five executions get custom plans built for the actual value, and a custom plan can match the predicate. After that the server may switch to a generic plan when its estimated cost is close enough, and a generic plan can't use this index for that clause. Whether it switches depends on the cost comparison.
The rule I'm keeping is plain. A value that selects the partial index goes into the query text as a literal.
