pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Yuzuko Hosoya <hosoya.yuzuko@lab.ntt.co.jp>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Runtime pruning problem
Date: Tue, 30 Jul 2019 18:56:47 -0400
Message-ID: <8056.1564527407@sss.pgh.pa.us> (raw)
In-Reply-To: <7814.1564527032@sss.pgh.pa.us>
References: <001001d4f44b$2a2cca50$7e865ef0$@lab.ntt.co.jp>
	<CAKJS1f_4b9J7K7DSuZMkyga67OetfyAWz1xzYJd25HSf9-cijQ@mail.gmail.com>
	<b50238ec-e402-6fcb-7f3a-b74418471b29@lab.ntt.co.jp>
	<CAKJS1f98o-6-SWWzcfiJO6JAQFu2DnYWBzFVB0x2+u5ub=ASEA@mail.gmail.com>
	<c4acce90-8265-c91f-065f-e4507ad054bd@lab.ntt.co.jp>
	<2018.1555473241@sss.pgh.pa.us>
	<CAKJS1f9ch8rVy8ZhsV2J7q0zCq4xFuXWxTT90EadpkTsgCvQQw@mail.gmail.com>
	<2923.1555474214@sss.pgh.pa.us>
	<f1ad1911-df47-b555-8df5-825e3a8aa69c@lab.ntt.co.jp>
	<17368.1555608352@sss.pgh.pa.us>
	<CAKJS1f_020O9bX-c1cGcDM2L5DU44hRQ3k_0MXBBqKxAQ=X5bg@mail.gmail.com>
	<CAKJS1f_GZ6LtonDHBJ0pgwtT+OFWmJBap60Fb9iQ++it4aXCFA@mail.gmail.com>
	<CAKJS1f_mw47rnotO4VvpmH42cVKAPn0bkTCzevugGPqeQrW6uQ@mail.gmail.com>
	<CAKJS1f82v4fEtH-XkGfUq-QEDErYBvkH8BkmchAT53vUjD+g7Q@mail.gmail.com>
	<6779.1564525639@sss.pgh.pa.us>
	<CAKJS1f8NDUNRY=YEMj1-qkyGvJi4AOL7v7LsGNx1spZQf-P7mA@mail.gmail.com>
	<7814.1564527032@sss.pgh.pa.us>

I wrote:
> This may be arguing for a change in ruleutils' existing behavior,
> not sure.  But when dealing with traditional-style inheritance,
> I've always thought that Vars above the Append were referring to
> the parent rel in its capacity as the parent, not in its capacity
> as the first child.  With new-style partitioning drawing a clear
> distinction between the parent and all its children, it's easier
> to understand the difference.

OK, so experimenting, I see that it is a change: HEAD does

regression=# explain verbose select * from part order by a;
                                   QUERY PLAN                                   
---------------------------------------------------------------------------------
 Sort  (cost=362.21..373.51 rows=4520 width=8)
   Output: part_p1.a, part_p1.b
   Sort Key: part_p1.a
   ->  Append  (cost=0.00..87.80 rows=4520 width=8)
         ->  Seq Scan on public.part_p1  (cost=0.00..32.60 rows=2260 width=8)
               Output: part_p1.a, part_p1.b
         ->  Seq Scan on public.part_p2_p1  (cost=0.00..32.60 rows=2260 width=8)
               Output: part_p2_p1.a, part_p2_p1.b
(8 rows)

The portion of this below the Append is fine, but I argue that
the Vars above the Append should say "part", not "part_p1".
In that way they'd look the same regardless of which partitions
have been pruned or not.

			regards, tom lane





view thread (38+ messages)  latest in thread

Message-ID: <8056.1564527407@sss.pgh.pa.us>
Permalink:  ../8056.1564527407@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/8056.1564527407@sss.pgh.pa.us

 · 

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, david.rowley@2ndquadrant.com, Langote_Amit_f8@lab.ntt.co.jp, hosoya.yuzuko@lab.ntt.co.jp, pgsql-hackers@lists.postgresql.org
  Subject: Re: Runtime pruning problem
  In-Reply-To: <8056.1564527407@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