Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch
От | Tom Lane |
---|---|
Тема | Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch |
Дата | |
Msg-id | 14986.1427037326@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch
|
Список | pgsql-bugs |
"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
В списке pgsql-bugs по дате отправления: