Re: why partition pruning doesn't work?

From: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: why partition pruning doesn't work?
Date: 2018-06-12 13:34:14
Message-ID: CAFjFpRe05ChwFcmrSkFVs5PaAbxgwAHOC8xA2MWQqGhjTbfr-Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 12, 2018 at 3:54 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Not sure about a good fix for this. It seems annoying to copy the
> rel's whole partkey data structure into query-local storage, but
> I'm not sure we have any choice. On the bright side, there might
> be an opportunity to get rid of repeated runtime fmgr_info lookups
> in cross-type comparison situations.
>

We already do that while building part_scheme. So, if we are in
planner, it's readily available through RelOptInfo. If we need it in
the executor, we need to pass it down from RelOptInfo into one of the
execution states. I haven't looked at the patch to exactly figure out
which of these is true.

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2018-06-12 13:37:24 Re: assert in nested SQL procedure call in current HEAD
Previous Message Ashutosh Bapat 2018-06-12 13:22:40 Re: Remove mention in docs that foreign keys on partitioned tables are not supported