Re: deb package sizes

On Thu, 9 Jan 2025 17:06:57 +0100
Álvaro Hernández <aht(at)ongres(dot)com> wrote:

> 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
>
> * Security analysis. Unneeded files (specially binaries, but not

Another concern is the impact of image rebuilds as dependencies are
updated. Tianon (a primary maintainer of the docker images) has noted
that they limit frequency of the debian base containers, because every
rebuild of the base container triggers an avalance of downstream
rebuilds. CNPG was doing daily rebuilds for awhile, and every time any
python dependency was updated you'd get a new image - boto3 was
notorious for very frequent updates. So with a different image version
for every day, a single server running multiple copies of postgres might
easily end up with multiple image versions on the server as copies are
slowly updated.

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

To be clear, I definitely don't want the "default" postgres packages to
not have JIT. I was just suggesting a non-default "slim" alternative.

Honestly I don't know if this is going to introduce a bunch of
complexity in dependency management between debian packages, and how
feasible it would be actually do it... but wanted to ask the question
and raise the topic.

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

Yes, I'm definitely well aware of how ICU isn't really changing
anything about rebuild requirement - I've said many times that people
should default to builtin C collation starting with pg17, and set
linguistic collation at a table or query level. The big advantage of
this is that it's much easier to know everything that needs rebuilding,
since postgres does good dependency tracking of objects using nondefault
collation.

But with ICU there is at least the option that someone could rebuild an
old version and run it on the new debian release. That's nearly
impossible with glibc.

-Jeremy