Re: WIP: expression evaluation improvements - Mailing list pgsql-hackers

From Soumyadeep Chakraborty
Subject Re: WIP: expression evaluation improvements
Date
Msg-id CADwEdorztKbJuwbk=H7FhhdStam404fC23RK2PJhz=xLkqbG3A@mail.gmail.com
Whole thread Raw
In response to Re: WIP: expression evaluation improvements  (Andres Freund <andres@anarazel.de>)
Responses Re: WIP: expression evaluation improvements
List 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

pgsql-hackers by date:

Previous
From: Soumyadeep Chakraborty
Date:
Subject: Re: WIP: expression evaluation improvements
Next
From: Yugo NAGATA
Date:
Subject: Re: Implementing Incremental View Maintenance