From: | Soumyadeep Chakraborty <sochakraborty(at)pivotal(dot)io> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: expression evaluation improvements |
Date: | 2020-02-10 01:29:21 |
Message-ID: | CADwEdorztKbJuwbk=H7FhhdStam404fC23RK2PJhz=xLkqbG3A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Yugo NAGATA | 2020-02-10 01:37:50 | Re: Implementing Incremental View Maintenance |
Previous Message | Soumyadeep Chakraborty | 2020-02-10 01:28:02 | Re: WIP: expression evaluation improvements |