Re: why partition pruning doesn't work?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, 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-18 13:32:52
Message-ID: 7500.1531920772@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> writes:
> On 2018/07/16 2:02, Tom Lane wrote:
>> BTW, there'd be a lot to be said for having InitPlan just open all
>> the rels and build an array of Relation pointers that parallels the
>> RTE list, rather than doing heap_opens in random places elsewhere.

> +1 to this. Actually I had written such a patch in place of the one I
> posted on this thread, but wasn't confident enough that I had found and
> fixed all the places in the executor that would use the Relation pointer
> from there instead of fetching it themselves.

Well, it doesn't have to be a 100% conversion, especially not to start
out with. As long as we ensure that common code paths through the
executor have only one open/close per rel, I don't think it matters
too much if there are some corner cases with more.

Also, tracking down places like that wouldn't be that hard to do. One
could instrument the relcache to report situations where a rel's refcount
gets above 1. (The infrastructure for logging backtraces that's being
discussed in other threads would help here.) We might decide that
particular cases weren't worth fixing --- eg if the extra open is
happening in code that doesn't have easy access to the EState --- but
I doubt that finding them is impractical.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2018-07-18 13:58:58 Re: [HACKERS] PoC: full merge join on comparison clause
Previous Message Peter Eisentraut 2018-07-18 13:32:46 Re: Alter index rename concurrently to