|From:||Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>|
|To:||Andres Freund <andres(at)anarazel(dot)de>|
|Cc:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Kohei KaiGai <kaigai(at)heterodb(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>|
|Subject:||Re: [HACKERS] path toward faster partition pruning|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Andres Freund wrote:
> On 2018-04-07 08:13:23 -0300, Alvaro Herrera wrote:
> > Andres Freund wrote:
> > > I've also attempted to fix rhinoceros's failure I remarked upon a couple
> > > hours ago in
> > > https://firstname.lastname@example.org
> > And this, too. I was unsure if this was because we were missing calling
> > some object access hook from the new code, or the additional pruning.
> That's possible. I did attempt to skim the code, that's where my
> complain about the docs originated. There certainly isn't an
> InvokeFunctionExecuteHook() present. It's not clear to me whether
> that's an issue - we don't invoke the hooks in a significant number of
> places either, and as far as I can discern there's not much rule or
> reason about where we invoke it.
I managed to convince myself that it's not higher-level code's
responsibility to invoke the execute hooks; the likelihood of bugs of
omission seems just too large. But maybe I'm wrong.
There's a small number of InvokeFunctionExecuteHook calls in the
executor, but I really doubt that it exhaustively covers everyplace
where catalogued functions are called in the executor.
CC'ing KaiGai and Stephen Frost; they may want to chip in here.
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
|Next Message||Teodor Sigaev||2018-04-07 20:02:08||Re: WIP: Covering + unique indexes.|
|Previous Message||Andres Freund||2018-04-07 19:32:15||Re: [sqlsmith] Segfault in expand_tuple|