On Mon, Dec 9, 2019 at 11:21 AM Tom Lane <tgl@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