pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedFrom: Antonin Houska <ah@cybertec.at>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Corey Huinker <corey.huinker@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: More efficient RI checks - take 2
Date: Thu, 23 Apr 2020 08:29:33 +0200
Message-ID: <29560.1587623373@antos> (raw)
In-Reply-To: <CAFj8pRBNKrTYZLQt6qd09ikm4ZF+XQB4R+bFHHag7cuCXrOL0A@mail.gmail.com>
References: <20200422154231.6shz4kdor4yb5w5b@alap3.anarazel.de>
<20200422171806.GA12435@alvherre.pgsql>
<CA+TgmoZF_fkSYTcY7=yiRr7MxC=yt1VoZPMcYfwsRYw6TusEmA@mail.gmail.com>
<20200422183600.tpl5745dfbnozi6t@alap3.anarazel.de>
<CA+Tgmobb2_sm8PZ16_dqevUktcjT8OnZ5xvv=AFtxWWjf28VxA@mail.gmail.com>
<6442.1587595207@sss.pgh.pa.us>
<28826.1587618482@antos>
<CAFj8pRBNKrTYZLQt6qd09ikm4ZF+XQB4R+bFHHag7cuCXrOL0A@mail.gmail.com>
Pavel Stehule <pavel.stehule@gmail.com> wrote:
> čt 23. 4. 2020 v 7:06 odesílatel Antonin Houska <ah@cybertec.at> napsal:
>
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> > 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?
I think that at some point it estimates the number of rows from the number of
table pages, but I don't remember details.
I wanted to say that if we constructed the plan "manually", we'd need at least
two substantially different variants: one to check many rows and the other to
check a single row.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
view thread (35+ messages) latest in thread
Message-ID: <29560.1587623373@antos>
Permalink: ../29560.1587623373@antos/
Also on: postgresql.org/message-id/29560.1587623373@antos
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: ah@cybertec.at, pavel.stehule@gmail.com, tgl@sss.pgh.pa.us, robertmhaas@gmail.com, andres@anarazel.de, alvherre@2ndquadrant.com, corey.huinker@gmail.com
Subject: Re: More efficient RI checks - take 2
In-Reply-To: <29560.1587623373@antos>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox