Tom, all, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Craig Ringer <craig.rin...@2ndquadrant.com> writes: > > We're carefully maintaining this bizarre cognitive dissonance where we > > justify the need for using this as a planner hint at the same time as > > denying that we have a hint. That makes it hard to make progress here. > > I think there's fear that we're setting some kind of precedent by > > admitting what we already have. > > I think you're overstating the case. It's clear that there's a > significant subset of CTE functionality where there has to be an > optimization fence. The initial implementation basically took the > easy way out by deeming *all* CTEs to be optimization fences. Maybe > we shouldn't have documented that behavior, but we did. Now we're > arguing about how much of a compatibility break it'd be to change that > planner behavior. I don't see any particular cognitive dissonance here, > just disagreements about the extent to which backwards compatibility is > more important than better query optimization.
This really begs the question of if it's "better." If it's always better, then there's no discussion to be had. If there are cases where it's not, then that could cause problems for people and there's a reason to question if we're ok with that. Of course, if a user runs into such an issue, there's a few ways they can address it without needs any additional syntax (use a temp table instead, introduce a volative function into the CTE, etc). I had originally been on the fence about this myself, and even advocated the new-syntax approach at one point (as I recall), but with the new statistics we're gaining and the improvmenets in the planner, along with parallel query and the advantages offered by being able to pull a CTE into the main query, I think I've come around to agree that removing the optimization fence, when it won't change the resullts, is a good thing to do. Thanks! Stephen
signature.asc
Description: Digital signature
