David Kamholz writes:
> 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 and executed, can you?
Yes, you can. Especially so for prepared statements.
r
>
> > 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
2017-12-21 15:19 GMT+01:00 Tom Lane :
> Pavel Stehule writes:
> > 2017-12-20 23:41 GMT+01:00 Tom Lane :
> >> Hm, scratch that --- experimentation shows that the parser still
> produces
> >> a CoerceToDomain node in that case, not a literal of the domain type.
>
> > Why the rewrite doesn't reduce
Pavel Stehule writes:
> 2017-12-20 23:41 GMT+01:00 Tom Lane :
>> Hm, scratch that --- experimentation shows that the parser still produces
>> a CoerceToDomain node in that case, not a literal of the domain type.
> Why the rewrite doesn't reduce it? Or why parser does it?
Because ALTER DOMAIN can
Hi
2017-12-20 23:41 GMT+01:00 Tom Lane :
> I wrote:
> > 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 wrote:
> 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.
Hm, scratch that --- experimentation shows that the pars
>
> 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
Robert Haas writes:
> On Wed, Dec 20, 2017 at 1:03 AM, David Kamholz wrote:
>> Note that in the above plan, 'spa-000' is cast to text before it's cast to
>> uid. This
>> is apparently connected to why postgresql can't choose the better plan.
> It's slightly hard for me to follow what's going on
>
> 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'
On Wed, Dec 20, 2017 at 1:03 AM, David Kamholz wrote:
> I've recently come across a query that produces different plans depending on
> whether it's parameterized or not.
That's not too surprising. PostgreSQL can't choose a plan based on
the parameter value when it doesn't know the parameter valu
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
11 matches
Mail list logo
