Re: WIP: expression evaluation improvements

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

In response to

Responses

Browse pgsql-hackers by date

  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