Horton

Re: WIP: expression evaluation improvements

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Soumyadeep Chakraborty <sochakraborty@pivotal.io>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2020-02-07T06:35:13Z
Lists: pgsql-hackers 
Hi,

On 2019-10-28 23:58:11 -0700, Soumyadeep Chakraborty wrote:
> > Sorry for not replying to that earlier.  I'm not quite sure it's
> > actually worthwhile doing so - did you try to measure any memory / cpu
> > savings?
> 
> No problem, thanks for the reply! Unfortunately, I did not do anything
> significant in terms of mem/cpu measurements. However, I have noticed
> non-trivial differences between optimized and unoptimized .bc files
> that were dumped from time to time.

Could you expand on what you mean here? Are you saying that you got
significantly better optimization results by doing function optimization
early on?  That'd be surprising imo?

Greetings,

Andres Freund

Commits

  1. Add special case fast-paths for strict functions

  2. Replace EEOP_DONE with special steps for return/no return

  3. jit: Reference expression step functions via llvmjit_types.

  4. jit: Remove redundancies in expression evaluation code generation.

  5. expression eval: Don't redundantly keep track of AggState.

  6. jit: Reference functions by name in IOCOERCE steps.

  7. expression eval, jit: Minor code cleanups.