From: | Álvaro Hernández <aht(at)ongres(dot)com> |
---|---|
To: | Christoph Berg <myon(at)debian(dot)org>, pgsql-pkg-debian(at)lists(dot)postgresql(dot)org |
Subject: | Re: deb package sizes |
Date: | 2025-01-09 16:06:57 |
Message-ID: | bf542776-4c08-403b-9353-ed2bb3579589@ongres.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-pkg-debian |
On 9/1/25 10:07, Christoph Berg wrote:
> Re: Jeremy Schneider
>> I'm wondering if there might be any support for providing a
>> "postgresql-slim" package on PGDG which excludes llvm and python? I
>> think this might almost cut the total install size in half, and I think
>> there might be many users who would value having the option.
> Hi,
>
> could you explain why 250 MB is too much? Disk space these days is
> ultra cheap
Hi Christoph.
Container images allow (are meant to) contain only the necessary
files needed to run the process that will be run when the image is run.
As such, any additional file poses two main problems:
* Disk space is cheap. Bandwidth not so much. Time to start a container
may have a notable cost. Making container images slimmer helps in all
these dimensions. When you run the same container image in many places,
with high frequency, and end up pulling it multiple times, it all that
has a cost. In particular for Postgres, time pulling and running an
image may affect uptime. So it can become quite important.
* Security analysis. Unneeded files (specially binaries, but not only)
may lead to container images having (more) security vulnerabilities than
they could. For many, container images must pass vulnerability analysis
scans, and the more (unneeded) packages present, the bigger the chances
are that they may contain vulnerabilities. It's anyway a basic security
principle, to only contain the files needed to run the files needed, and
no more.
> and removing functionality (query JITing) does have cost
> as well.
If it can be made optional, then users can decide whether they want
container images with this functionality or not.
>> Even though ICU is a larger package, I would argue for still
>> including it in a "slim" build. Because of the drama around glibc
>> collation I view ICU as especially important to make available.
> Note that ICU does not fix the collation drama either, you will have
> to reindex on ICU upgrades as well.
Agreed that it doesn't solve the whole drama, but reindexes are not
needed if container images for upgrades are provided while keeping the
ICU version constant (which is doable).
Álvaro
From | Date | Subject | |
---|---|---|---|
Next Message | Jeremy Schneider | 2025-01-09 17:08:45 | Re: deb package sizes |
Previous Message | Álvaro Hernández | 2025-01-09 15:43:16 | Re: deb package sizes |