"David G. Johnston" <david.g.johnston@gmail.com> writes:
> This doesn't seem like a solution...if the flattened version of an all
> constants invocation cannot be run only once where it could if it was not
> flattened I would say the we've introduced a likely (and actual)
> performance regression that punishes current valid and idiomatic code. I
> haven't gone back and devised the entire reasoning for, and potential
> benefit of, the flattening but both this and likely functions returning
> composites are being negatively affected by this change.
Well, it improves some queries and perhaps punishes others, but I should
think the overall effect would generally be a win. Even in the case given
here, it's far from clear that allowing flattening is a performance loss;
the end result would have been a query containing only constants at run
time, which in most scenarios would be a Good Thing.
As for claiming that this is broken and should be reverted: nyet. In the
first place, there is certainly no PG documentation anywhere that promises
single evaluation of a function written in the manner shown here. We do,
on the other hand, say that OFFSET 0 creates an optimization fence; so
I see nothing wrong with my recommendation. In the second place, this was
a HEAD-only change, and we certainly do not promise than the planner never
changes behavior in major version updates.
regards, tom lane
