Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: > > Right -- the idea I was talking about was to create a Plan tree > > without using the main planner. So it wouldn't bother costing an index > > scan on each index, and a sequential scan, on the target table - it > > would just make an index scan plan, or maybe an index path that it > > would then convert to an index plan. Or something like that. > > Consing up a Path tree and then letting create_plan() make it into > an executable plan might not be a terrible idea. There's a whole > boatload of finicky details that you could avoid that way, like > everything in setrefs.c. > > But it's not entirely clear to me that we know the best plan for a > statement-level RI action with sufficient certainty to go that way. > Is it really the case that the plan would not vary based on how > many tuples there are to check, for example?
I'm concerned about that too. With my patch the checks become a bit slower if only a single row is processed. The problem seems to be that the planner is not entirely convinced about that the number of input rows, so it can still build a plan that expects many rows. For example (as I mentioned elsewhere in the thread), a hash join where the hash table only contains one tuple. Or similarly a sort node for a single input tuple. -- Antonin Houska Web: https://www.cybertec-postgresql.com
