pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feed From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: David Rowley <david.rowley@2ndquadrant.com>
Cc: Imai, Yoshikazu <imai.yoshikazu@jp.fujitsu.com>
Cc: Amit Langote <amitlangote09@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: speeding up planning with partitions
Date: Mon, 18 Feb 2019 12:27:35 -0500
Message-ID: <30972.1550510855@sss.pgh.pa.us> (raw )
In-Reply-To: <b8a139b8-2f5d-6079-67b2-99957af3fc36@lab.ntt.co.jp >
References: <8ea8bbb1-31ff-a469-02a7-281c3eba4bea@lab.ntt.co.jp >
<201902011001.4v25uw6w6kb5@alvherre.pgsql >
<CAKJS1f9LkQ=w4cq2_OaW05=mw8H_jQofWHiK0w3VVP-nSkUUmA@mail.gmail.com >
<CA+HiwqFioAonMAgE0OWZeK=NEEOKmq-c=iYR2pkPOO=q6NxMkg@mail.gmail.com >
<e85c4b41-80d6-1045-d934-feeca4a463ab@lab.ntt.co.jp >
<0F97FA9ABBDBE54F91744A9B37151A5127865E@g01jpexmbkw24 >
<5d00eb35-375d-0672-0626-96bdb86829d0@lab.ntt.co.jp >
<CAKJS1f9XAePd2+8F4=wtHKdDdckgKcSoXb-ZbU8Wbt86mhLxKA@mail.gmail.com >
<b8a139b8-2f5d-6079-67b2-99957af3fc36@lab.ntt.co.jp >
Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
> [ v22 patch set ]
I started to look at this, and immediately choked on the 0001 patch:
if (childpruned ||
!apply_child_basequals(root, rel, childrel, childRTE, appinfo) ||
relation_excluded_by_constraints(root, childrel, childRTE))
{
Frankly, that code is just horrid. Having a function with side effects
in an if-test is questionable at the best of times, and having it be
the second of three conditions (which the third condition silently depends
on) is unreadable and unmaintainable.
I think the existing code here is considerably cleaner than what this
patch proposes.
I suppose you are doing this because you intend to jam some additional
cleanup code into the successfully-pruned-it code path, but if said
code is really too bulky to have multiple copies of, couldn't you
put it into a subroutine? You're not going to be able to get to only
one copy of such cleanup anyhow, because there is another early-exit
further down, for the case where set_rel_size detects dummy-ness.
regards, tom lane
view thread (265+ messages) latest in thread
Message-ID: <30972.1550510855@sss.pgh.pa.us>
Permalink: ../30972.1550510855@sss.pgh.pa.us/
Also on: postgresql.org/message-id/30972.1550510855@sss.pgh.pa.us
copy link · copy postgr.es
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: tgl@sss.pgh.pa.us, Langote_Amit_f8@lab.ntt.co.jp, david.rowley@2ndquadrant.com, imai.yoshikazu@jp.fujitsu.com, amitlangote09@gmail.com, alvherre@2ndquadrant.com
Subject: Re: speeding up planning with partitions
In-Reply-To: <30972.1550510855@sss.pgh.pa.us>
* 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