Horton

Re: WIP: expression evaluation improvements

Soumyadeep Chakraborty <sochakraborty@pivotal.io>

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

> 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?

Sorry for the ambiguity, I meant that I had observed differences in the
sizes
of the bitcode files dumped.

These are the size differences that I observed (for TPCH Q1):
Without my patch:
-rw-------   1 pivotal  staff   278K Feb  9 11:59 1021.0.bc
-rw-------   1 pivotal  staff   249K Feb  9 11:59 1374.0.bc
-rw-------   1 pivotal  staff   249K Feb  9 11:59 1375.0.bc
With my patch:
-rw-------   1 pivotal  staff   245K Feb  9 11:43 88514.0.bc
-rw-------   1 pivotal  staff   245K Feb  9 11:43 88515.0.bc
-rw-------   1 pivotal  staff   270K Feb  9 11:43 79323.0.bc

This means that the sizes of the module when execution encountered:

if (jit_dump_bitcode)
{
char *filename;

filename = psprintf("%u.%zu.bc",
MyProcPid,
context->module_generation);
LLVMWriteBitcodeToFile(context->module, filename);
pfree(filename);
}

were smaller with my patch applied. This means there is less memory
pressure between when the functions were built and when
llvm_compile_module() is called. I don't know if the difference is
practically
significant.

Soumyadeep

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.