>
> > Why the rewrite doesn't reduce it? Or why parser does it?
>
> Because ALTER DOMAIN can change what would be a valid value.
In the view case that makes sense, but I don't see how ALTER DOMAIN is
relevant to my original example. You can't alter a domain between the time
the query is parsed an
>
> You might consider whether you can write 'spa-000'::uid explicitly in your
> query; that results in immediate application of the domain coercion, so
> that the planner no longer sees that as a run-time operation it has to
> avoid.
>
I should have mentioned that I tried an explicit cast and fou
>
> That's not too surprising. PostgreSQL can't choose a plan based on
> the parameter value when it doesn't know the parameter value
I thought that since 9.2, postgresql could "generate plans based on the
parameter value even when using prepared statements" (paraphrase of 9.2
release notes). I'
I've recently come across a query that produces different plans depending
on whether it's parameterized or not. The parameterized query takes ~50ms
while the non-parameterized query takes ~4s. The issue seems to be that the
query contains a STABLE function (uid_langvar) whose parameter is a domain
