On Wed, 29 Jul 2020 at 09:28, Andres Freund wrote:
> FWIW, I created a demo workload for this, and repro'ed the issue with
> that. Those improvements does make a very significant difference:
> Before:
> Timing: Generation 335.345 ms, Inlining 51.025 ms, Optimization 11967.776
> ms, Emission
On Wed, 29 Jul 2020 at 09:07, Andres Freund wrote:
> On 2020-07-28 11:54:53 +1200, David Rowley wrote:
> > Is there some reason that we can't consider jitting on a more granular
> > basis?
>
> There's a substantial "constant" overhead of doing JIT. And that it's
> nontrival to determine which part
Hi,
On 2020-07-28 14:07:48 -0700, Andres Freund wrote:
> (I'm rebasing my tree that tries to reduce the overhead / allow caching
> / increase efficiency to current PG, but it's a fair bit of work)
FWIW, I created a demo workload for this, and repro'ed the issue with
that. Those improvements does
Hi,
On 2020-07-28 11:54:53 +1200, David Rowley wrote:
> Is there some reason that we can't consider jitting on a more granular
> basis?
There's a substantial "constant" overhead of doing JIT. And that it's
nontrival to determine which parts of the query should be JITed in one
part, and which not.
Andres Freund writes:
> On 2020-07-27 19:02:56 -0400, Alvaro Herrera wrote:
>>> I don't quite understand why is it that a table with 1000 partitions
>>> means that JIT compiles the thing 1000 times. Sure, it is possible that
>>> some partitions have a different column layout, but it seems an easy
Hi,
On 2020-07-27 19:02:56 -0400, Alvaro Herrera wrote:
> On 2020-Jul-27, Scott Ribe wrote:
>
> > > On Jul 27, 2020, at 4:00 PM, Alvaro Herrera
> > > wrote:
> > >
> > > I don't quite understand why is it that a table with 1000 partitions
> > > means that JIT compiles the thing 1000 times. Sur
On Tue, 28 Jul 2020 at 11:00, Andres Freund wrote:
>
> On 2020-07-25 10:54:18 -0400, Tom Lane wrote:
> > David Rowley 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
On 2020-Jul-27, Scott Ribe wrote:
> > On Jul 27, 2020, at 4:00 PM, Alvaro Herrera
> > wrote:
> >
> > I don't quite understand why is it that a table with 1000 partitions
> > means that JIT compiles the thing 1000 times. Sure, it is possible that
> > some partitions have a different column layo
Hi,
On 2020-07-25 10:54:18 -0400, Tom Lane wrote:
> David Rowley 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-readi
> On Jul 27, 2020, at 4:00 PM, Alvaro Herrera wrote:
>
> I don't quite understand why is it that a table with 1000 partitions
> means that JIT compiles the thing 1000 times. Sure, it is possible that
> some partitions have a different column layout, but it seems an easy bet
> that most cases are
On 2020-Jul-24, Andres Freund wrote:
> I think the issue is more that we need to take into accoutn that the
> overhead of JITing scales ~linearly with the number of JITed
> expressions. And that's not done right now. I've had a patch somewhere
> that had a prototype implementation of changing the
On Sun, 26 Jul 2020 at 02:54, Tom Lane wrote:
>
> David Rowley 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
On Sun, 26 Jul 2020 at 02:23, Tom Lane wrote:
>
> Andres Freund writes:
> > On 2020-07-24 18:37:02 -0400, Tom Lane wrote:
> >> Yeah. I'm fairly convinced that the v12 defaults are far too low,
> >> because we are constantly seeing complaints of this sort.
>
> > I think the issue is more that we
On Sun, 26 Jul 2020 at 02:17, Tom Lane wrote:
>
> David Rowley writes:
> > On Sat, 25 Jul 2020 at 10:42, David Rowley wrote:
> >> I think plan cost overestimation is a common cause of unwanted jit too.
> >> It would be good to see the EXPLAIN ANALYZE so we knew if that was the
> >> case here.
>
David Rowley 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 pl
Andres Freund writes:
> On 2020-07-24 18:37:02 -0400, Tom Lane wrote:
>> Yeah. I'm fairly convinced that the v12 defaults are far too low,
>> because we are constantly seeing complaints of this sort.
> I think the issue is more that we need to take into accoutn that the
> overhead of JITing scal
David Rowley writes:
> On Sat, 25 Jul 2020 at 10:42, David Rowley wrote:
>> I think plan cost overestimation is a common cause of unwanted jit too.
>> It would be good to see the EXPLAIN ANALYZE so we knew if that was the
>> case here.
> So Scott did send me the full EXPLAIN ANALYZE for this pri
On Sat, 25 Jul 2020 at 10:42, David Rowley wrote:
>
> On Sat, 25 Jul 2020 at 10:37, Tom Lane wrote:
> >
> > David Rowley writes:
> > > However, for now, you might just want to try raising various jit
> > > thresholds so that it only is enabled for more expensive plans.
> >
> > Yeah. I'm fairly
Hi,
On Fri, Jul 24, 2020, at 15:32, Scott Ribe wrote:
> > On Jul 24, 2020, at 4:26 PM, David Rowley wrote:
> >
> > It does not really take into account the cost of jitting.
>
> That is what I was missing.
>
> I read about JIT when 12 was pre-release; in re-reading after my post I
> see that i
Hi,
On 2020-07-24 18:37:02 -0400, Tom Lane wrote:
> David Rowley writes:
> > However, for now, you might just want to try raising various jit
> > thresholds so that it only is enabled for more expensive plans.
>
> Yeah. I'm fairly convinced that the v12 defaults are far too low,
> because we ar
> On Jul 24, 2020, at 4:37 PM, Tom Lane wrote:
>
> Yeah. I'm fairly convinced that the v12 defaults are far too low,
> because we are constantly seeing complaints of this sort.
They are certainly too low for our case; not sure if for folks who are not
partitioning if they're way too low.
The
On Sat, 25 Jul 2020 at 10:37, Tom Lane wrote:
>
> David Rowley writes:
> > However, for now, you might just want to try raising various jit
> > thresholds so that it only is enabled for more expensive plans.
>
> Yeah. I'm fairly convinced that the v12 defaults are far too low,
> because we are c
David Rowley writes:
> However, for now, you might just want to try raising various jit
> thresholds so that it only is enabled for more expensive plans.
Yeah. I'm fairly convinced that the v12 defaults are far too low,
because we are constantly seeing complaints of this sort.
> On Jul 24, 2020, at 4:26 PM, David Rowley wrote:
>
> It does not really take into account the cost of jitting.
That is what I was missing.
I read about JIT when 12 was pre-release; in re-reading after my post I see
that it does not attempt to estimate JIT cost. And in thinking about it, I
r
On Sat, 25 Jul 2020 at 08:46, Scott Ribe wrote:
> Given the magnitude of the miss in using JIT here, I am wondering: is it
> possible that the planner does not properly take into account the cost of
> JIT'ing a function for multiple partitions? Or is it that the planner doesn't
> have enough in
I have come across a case where PG 12 with default JIT settings makes a
dramatically bad decision. PG11 without JIT, executes the query in <1ms, PG12
with JIT takes 7s--and explain analyze attributes all that time to JIT. (The
plan is the same on both 11 & 12, it's just the JIT.)
It is a compl
26 matches
Mail list logo
