Hi Mikael, > We use static linking and link time optimization to squeeze the last bits of > performance out of the code in our most performance-critical queries, and it > simplifies our security audits to have a static binary running inside > chainguard/static as the data we handle is sensitive/business critical.
No comments about the security aspect. I'm not a security expert so I leave this topic for somebody for whom this is an area of expertise. I don't buy the optimization part. The performance gain you get is next to nothing compared to the time spent transferring SQL queries over the network / UDP sockets, parsing and planning them, accessing the disk, waiting for the locks, etc. Unless you actually measured it in order to show the opposite which I seriously doubt you did. A better time investment would be finding actual bottlenecks in the given system in order to be able to eliminate them. > Aleksander, do you have something against static linking or am I reading you > wrong? I've seen this sentiment in several places but never understood why > anyone would hold this position. Could you elaborate? The question is whether it's practical for the PostgreSQL community to put effort into supporting / testing static linking of libpq. Personally I'm not convinced that demanding from every open-source project in existence to support static linking is a sustainable idea in the long run, given the fact that there are technologies like Docker and programming languages like Go (with pgx client). -- Best regards, Aleksander Alekseev
