"Jim C. Nasby" <jim@xxxxxxxxx> writes: > Let me clarify, because that's not what I meant. Right now, there's not > even a shadow of a design for anything else, and this is a tough nut to > crack. I think you are not exactly measuring on a level playing field. On the textually-embedded-hints side, I see a very handwavy suggestion of a syntax and absolutely nothing about how it might be implemented --- in particular, nothing about how the information would be transmitted through to the planner, and nothing about exactly how the planner would use it if it had it. (No, I don't think "the planner will obey the hints" is an implementation sketch.) On the other side, the concept of system catalog(s) containing overrides for statistical or costing estimates is pretty handwavy too, but at least it's perfectly clear where it would plug into the planner: before running one of the current stats estimation or costing functions, we'd look for a matching override command in the catalogs. The main question seems to be what we'd like to be able to match on ... but that doesn't sound amazingly harder than specifying what an embedded hint does. IMO a textual hint facility will actually require *more* infrastructure code to be written than what's being suggested for alternatives. regards, tom lane
