Re: Optimizing PostgreSQL with LLVM's PGO+LTO

From: Darafei "Komяpa" Praliaskouski <me(at)komzpa(dot)net>
To: João Paulo Labegalini de Carvalho <jaopaulolc(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Optimizing PostgreSQL with LLVM's PGO+LTO
Date: 2023-01-27 19:09:14
Message-ID: CAC8Q8tKCVWCNWHYs4g_yjngC6QkJ6s27J+7We4ERcdcGwptUbg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

We have implemented LTO in PostGIS's build system a couple releases ago. It
definitely gives +10% on heavy maths. Unfortunately we did not manage to
get it running under FreeBSD because of default system linker issues so we
had to hide it under --with-lto switch which we recommend to everyone.

I did not experiment with Postgres itself but there are definitely traces
of numerous LTO-enabled private builds on the web.

On Fri, Jan 27, 2023 at 8:05 PM João Paulo Labegalini de Carvalho <
jaopaulolc(at)gmail(dot)com> wrote:

> Hi all,
>
> I am investigating the benefits of different profile-guided optimizations
> (PGO) and link-time optimizations (LTO) versus binary optimizers (e.g.
> BOLT) for applications such as PostgreSQL.
>
> I am facing issues when applying LTO to PostgreSQL as the produced binary
> seems broken (the server dies quickly after it has started). This is
> definitely a compiler bug, but I was wondering if anyone here have
> experimented with LTO for PostgreSQL.
>
> Thanks,
>
> --
> João Paulo L. de Carvalho
> Ph.D Computer Science | IC-UNICAMP | Campinas , SP - Brazil
> Postdoctoral Research Fellow | University of Alberta | Edmonton, AB -
> Canada
> joao(dot)carvalho(at)ic(dot)unicamp(dot)br
> joao(dot)carvalho(at)ualberta(dot)ca
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2023-01-27 19:41:25 Re: GUCs to control abbreviated sort keys
Previous Message Peter Geoghegan 2023-01-27 18:40:10 Re: New strategies for freezing, advancing relfrozenxid early