On 2020-Apr-22, Andres Freund wrote: > I assume that with constructing plans "manually" you don't mean to > create a plan tree, but to invoke parser/planner directly? I think > that'd likely be better than going through SPI, and there's precedent > too.
Well, I was actually thinking in building ready-made execution trees, bypassing the planner altogether. But apparently no one thinks that this is a good idea, and we don't have any code that does that already, so maybe it's not a great idea. However: > But honestly, my gut feeling is that for a lot of cases it'd be best > just bypass parser, planner *and* executor. And just do manual > systable_beginscan() style checks. For most cases we exactly know what > plan shape we expect, and going through the overhead of creating a query > string, parsing, planning, caching the previous steps, and creating an > executor tree for every check is a lot. Even just the amount of memory > for caching the plans can be substantial. Avoiding the executor altogether scares me, but I can't say exactly why. Foe example, you couldn't use foreign tables at either side of the FK -- but we don't allow FKs on those tables and we'd have to use some specific executor node for such a thing anyway. So this not a real argument against going that route. > Side note: I for one would appreciate a setting that just made all RI > actions requiring a seqscan error out... Hmm, interesting thought. I guess there are actual cases where it's not strictly necessary, for example where the referencing table is really tiny -- not the *referenced* table, note, since you need the UNIQUE index on that side in any case. I suppose that's not a really interesting case. I don't think this is implementable when going through SPI. > I think it's actually a good case where we will commonly be able to do > *better* than generic planning. The infrastructure for efficient > partition pruning exists (for COPY etc) - but isn't easily applicable to > generic plans. True. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
