Re: More efficient RI checks - take 2

čt 23. 4. 2020 v 7:06 odesílatel Antonin Houska <ah(at)cybertec(dot)at> napsal:

> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> > Robert Haas <robertmhaas(at)gmail(dot)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
>