2010/9/23 Robert Haas <robertmh...@gmail.com>: > All of this leaves me wondering why Greg ended up ifdefing out this > code in the first place. There's probably something I'm missing > here... but for now I can't think of a better idea than just removing > the #ifdefs and hoping that whatever problem they were causing was > limited to an earlier version of the code that no longer exists. >
Sorry, I haven't gone completely AWOL, I just hadn't noticed this thread. pgsql-hackers turns out to be kind of a lot of traffic if you're not reading it continuously. As you subsequently discovered I added these FIXMEs because without them the paths just didn't compare equal when it was comparing the paths of the children with the paths of the parent. I think the reason you had difficulty demonstrating problems with at least some of the FIXMEs was that they really aren't functionally necessary. They're there because when Tom implemented the equivalence classes he had a clear idea of what they were supposed to represent and what variables they needed to include to represent that. And including variables of child relations or subqueries of a UNION in an equivalence class representing the parent relation just didn't fit within that. It doesn't necessarily cause problems but it changes the data structure representation invariant from what he had in mind. I don't have a good grasp of exactly what the implications of changing this data structure rep invariant are though. Is having hundreds or thousands of variables in a single equivalence class (actually for a whole bunch if the pathkey list is long) going to cause performance problems? Is including variables that are only present for one child of the relation going to limit the usefulness of the equivalence class data structure for solving other problems where those columns really aren't equivalent? Also, since I don't really understand what's going on I wondered if there wasn't an obvious way to accomplish the same thing perhaps more efficiently. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
