Re: why partition pruning doesn't work?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(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>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(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-07-16 00:45:54
Message-ID: 15380.1531701954@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> On 16 July 2018 at 12:12, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Sun, Jul 15, 2018 at 1:02 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> What we'd be better off doing, if we go this route, is to install an
>>> assertion-build-only test that verifies during relation_open(NoLock)
>>> that some kind of lock is already held on the rel.

> Wouldn't it be better to just store the Relation indexed by its relid
> somewhere the first time we opened it? Then just do a direct array
> lookup on that rather than looking up by hashtable in syscache?

That would require carrying said array clear through from the parser to
the executor, plus we'd have some fun keeping it in sync with the RTE
changes that happen in the rewriter and planner, plus it's not entirely
clear where we'd close those relations in cases where the generated
plan isn't fed to the executor immediately (or gets copied in any way).
I don't think it's worth going that far.

I *do* think it might be worth behaving like that within the executor
by itself, and said so upthread. In that situation, we have a clear
place to do relation closes during ExecutorEnd, so it's not as messy
as a more general approach would be.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-07-16 00:55:38 Re: patch to allow disable of WAL recycling
Previous Message Robert Haas 2018-07-16 00:32:39 Re: patch to allow disable of WAL recycling