Re: bad JIT decision

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Scott Ribe <scott_ribe(at)elevated-dev(dot)com>, PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: bad JIT decision
Date: 2020-07-26 00:04:48
Message-ID: CAApHDvo+Wxzs8Pb_iPvT64j8vCFsnqQk8qwqvm2h-CLHSS1ahw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sun, 26 Jul 2020 at 02:54, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> > ... nested at the bottom level join, about 6 joins deep. The lack of
> > any row being found results in upper level joins not having to do
> > anything, and the majority of the plan is (never executed).
>
> On re-reading this, that last point struck me forcibly. If most of
> the plan never gets executed, could we avoid compiling it? That is,
> maybe JIT isn't JIT enough, and we should make compilation happen
> at first use of an expression not during executor startup.

That's interesting. But it would introduce an additional per
evaluation cost of checking if we're doing the first execution.

David

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Surya Widyanto 2020-07-26 01:17:01 Re: [SOLUTION] Slow or Cannot Connect to PostgreSQL Instance Service on Windows 10
Previous Message David Rowley 2020-07-26 00:03:42 Re: bad JIT decision