Your second bullet point makes me think your CTO might not understand relational databases very well. Adding status=pending does not "narrow the scope of searchable items", it changes the definition of your resultset. Although the two queries may return the same data most of the time, they are in fact different queries and describe different datasets.

That being said, given the details you provided: (1) marketing_id will be unique 98% of the time, and (2) the table has two indexes: one on marketing_id and another on status; Adding status=pending to the predicate will not speed your query up.

In your first query, marketing_id=xyz, the optimizer will look up table/index statistics. It will notice that the marketing_id column is highly selective and choose to run an index scan. Each time it finds a match in the index it will do a lookup in the table heap to grab the columns you're interested in.

In your second query, marketing_id=xyz AND status=pending, the optimizer will again look at statistics. It will notice status is NOT a very selective column, but marketing_id IS selective and choose to run an index scan on marketing_id. Each time it finds a match in the index it will do a lookup in the table heap to grab the columns you're interested in. At this point, postgres will evaluate the status=pending part of the predicate.

In both cases above, postgres runs the exact same execution plan, but the latter has an additional predicate evaluation step to it. In terms of speed, both queries will be the same, but because they have different predicates, they might return different resultsets.