On Mon, Dec 9, 2019 at 11:21 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > If we did go that route, I think a disable count would be the right thing. > It wouldn't take up any more space than a bool, probably, once you account > for padding overhead. And the code impact in hotspots like add_path would > be just about the same too. The advantage of a count is that, for > example, if you have enable_seqscan off then a path containing three > seqscans could be considered inferior to one with two; but if we have > only a bool then we can't tell the difference.
I'm not sure that I buy the idea that a disable count wouldn't take up any more space. A Boolean could even be represented as a flag inside of a bitmask, taking up just one bit. But even if you used a whole byte for it, in the long term, that's going to be cheaper; people around here are not blind to the value of filling in holes left by padding. I do agree that an integer would give us more accurate planning. The question in my mind is whether we care. It's not crazy to say that disabling is more for testing than real use, that it's best effort, and that once we give up on it, we give up completely -- which would make a bool sufficient. Now the contrary position that we want to be more accurate than that is not crazy either, and it's easy to see why that would be more convenient with a complex plan. But the real issue there, in my view, is that there's no way to disable certain kinds of plans for just part of a query. Nor is there any way to politely inform the planner that its idea of how many rows a certain scan or join will return is bollocks, and let it know the real number. There's just no way at all - except in limited cases, some unprincipled hacks - to give the planner that kind of guidance, suggestion, recommendation, urging, advice, clue, inkling, indicator, or, you know, whatever other word we could use to describe that sort of thing. So we're left with crude tools that affect the whole query. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
