A cached plan is shaped by the parameter values that were present when it was built, so if the first run asked for the one customer with two rows, the plan chosen may be a nested loop that is catastrophic for the customer with two million. The symptom is a query whose speed depends on who runs it, or which flips after a deploy or a restart. Fixes include forcing a custom plan, splitting the skewed case into its own statement, and giving the planner better statistics so both shapes are estimated correctly.
Article: PostgreSQL Prepared Statements and Plan Cache Pitfalls