On Thu, Apr 23, 2020 at 10:35 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > I think we're failing to communicate here. I agree that if the goal > is simply to re-implement what the RI triggers currently do --- that > is, retail one-row-at-a-time checks --- then we could probably dispense > with all the parser/planner/executor overhead and directly implement > an indexscan using an API at about the level genam.c provides. > (The issue of whether it's okay to require an index to be available is > annoying, but we could always fall back to the old ways if one is not.) > > However, what I thought this thread was about was switching to > statement-level RI checking. At that point, what we're talking > about is performing a join involving a not-known-in-advance number > of tuples on each side. If you think you can hard-wire the choice > of join technology and have it work well all the time, I'm going to > say with complete confidence that you are wrong. The planner spends > huge amounts of effort on that and still doesn't always get it right > ... but it does better than a hard-wired choice would do.
Oh, yeah. If we're talking about that, then getting by without using the planner doesn't seem feasible. Sorry, I guess I didn't read the thread carefully enough. As you say, perhaps there's room for both things, but also as you say, it's not obvious how to decide intelligently between them. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
