Date: Wed, 6 Mar 2019 10:32:57 -0800
From: Andres Freund <andres@anarazel.de>
To: Tobias Gierke <tobias.gierke@code-sourcery.de>
Cc: pgsql-performance@lists.postgresql.org
Subject: Re: JIT performance question
Message-ID: <20190306183257.lzdwpitvxehug3ag@alap3.anarazel.de>
References: <6191e1ee-d548-2a8c-d87d-dab63c05ad2e@code-sourcery.de>
 <20190306174258.f23avt6k3vtgqsqr@alap3.anarazel.de>
 <cd19a3f0-7c73-34dc-71e2-be2f69266537@code-sourcery.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cd19a3f0-7c73-34dc-71e2-be2f69266537@code-sourcery.de>
Precedence: bulk

Hi,

On 2019-03-06 19:21:33 +0100, Tobias Gierke wrote:
> On 06.03.19 18:42, Andres Freund wrote:
> > 
> > It's hard to know precisely without running a profile of the
> > workload. My suspicion is that the bottleneck in this query is the use
> > of numeric, which has fairly slow operations, including aggregation. And
> > they're too complicated to be inlined.
> > 
> > Generally there's definitely advantage in JITing aggregation.
> > 
> > There's a lot of further improvements on the table with better JIT code
> > generation, I just haven't gotten around implementing those :(
> 
> Thanks for the quick response ! I think you're onto something with the
> numeric type. I replaced it with bigint and repeated my test and now I get a
> nice 40% speedup

Cool. It'd really be worthwhile for somebody to work on adding fastpaths
to the numeric code...

Greetings,

Andres Freund