Robert Haas <robertmh...@gmail.com> writes: > I have to admit that I have a bad feeling about this. It strikes me > that there is no way we're not going to get complaints about a 35% > slowdown on planning a large join problem.
I have to admit that I'm worried about that too. However, I hope to continue whittling away at that number. It's also worth pointing out that the number is based on just a couple of test cases that are not very real-world, in that I'm testing against empty tables with no statistics. I think that this is a worst case, because it results in a lot of paths with basically the same costs, making them hard to prune; but I can't do much better, because the examples I've got were supplied without test data. Also, you're assuming that the changes have no upside whatsoever, which I fondly hope is not the case. Large join problems tend not to execute instantaneously --- so nobody is going to complain if the planner takes awhile longer but the resulting plan is enough better to buy that back. In my test cases, the planner *is* finding better plans, or at least ones with noticeably lower estimated costs. It's hard to gauge how much that translates to in real-world savings, since I don't have real data loaded up. I also think, though I've not tried to measure, that I've made planning cheaper for very simple queries by eliminating some overhead in those cases. Anyway, I'd be willing to hold off committing if someone were to volunteer to test an unintegrated copy of the patch against some moderately complicated application. But it's a sufficiently large patch that I don't really care to sit on it and try to maintain it outside the tree for a long time. > To be clear, I'd love to have this feature. But if there is a choice > between reducing planning time significantly for everyone and NOT > getting this feature, and increasing planning time significantly for > everyone and getting this feature, I think we will make more people > happy by doing the first one. We're not really talking about "are we going to accept or reject a specific feature". We're talking about whether we're going to decide that the last two years worth of planner development were headed in the wrong direction and we're now going to reject that and try to think of some entirely new concept. This isn't an isolated patch, it's the necessary next step in a multi-year development plan. The fact that it's a bit slower at the moment just means there's still work to do. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers