čt 23. 4. 2020 v 7:06 odesílatel Antonin Houska <a...@cybertec.at> napsal:
> 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. > without statistics the planner expect about 2000 rows table , no? Pavel > -- > Antonin Houska > Web: https://www.cybertec-postgresql.com >
