Date: Sun, 4 Aug 2019 03:12:32 -0400
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Amit Langote <amitlangote09@gmail.com>
Cc: yuzuko <yuzukohosoya@gmail.com>, shawn wang <shawn.wang.pg@gmail.com>,
	Shawn Wang <shawn.wang@highgo.ca>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Problem with default partition pruning
Message-ID: <20190804071232.GA7303@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20190804062925.GA5861@alvherre.pgsql>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

So this is the best commit messages I could come up with at this stupid
hour.  I think the wording is pretty poor but at least it seems correct.
I'm not sure I'll be able to get this pushed tomorrow, but I'll try.

  Improve pruning of a default partition

  When querying a partitioned table containing a default partition, we
  were wrongly deciding to include it in the scan too early in the
  process, failing to exclude it in some cases.  If we reinterpret the
  PruneStepResult.scan_default flag slightly, we can do a better job at
  detecting that it can be excluded.  The change is that we avoid setting
  the flag for that pruning step unless the step absolutely requires the
  default partition to be scanned (in contrast with the previous
  arrangement, which was to set it unless the step was able to prune it).
  So get_matching_partitions() must explicitly check the partition that
  each returned bound value corresponds to in order to determine whether
  the default one needs to be included, rather than relying on the flag
  from the final step result.

  Author: Yuzuko Hosoya <hosoya.yuzuko@lab.ntt.co.jp>
  Reviewed-by: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
  Discussion: https://postgr.es/m/00e601d4ca86$932b8bc0$b982a340$@lab.ntt.co.jp

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services