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