Bug 1221938

Summary: BCI PostgreSQL Image is too basic
Product: [openSUSE] PUBLIC SUSE Linux Enterprise Base Container Images Reporter: Jörg Sonnenberger <joerg>
Component: Channels/RepositoriesAssignee: BCI Internal Team <bci-internal>
Status: NEW --- QA Contact:
Severity: Enhancement    
Priority: P5 - None CC: joerg, max, meissner
Version: unspecifiedFlags: dmueller: needinfo? (joerg)
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Jörg Sonnenberger 2024-03-25 21:52:17 UTC 
The current BCI PostgreSQL images contain only the bare server, so for many deployment situations custom derived images have to be defined. It would be nice to serve a more useful set out of the box based on size vs functionality trade-offs.

(1) contrib is necessary for btree_gist and trigram indices
(2) plperl/plpython/pltcl provide the extension languages as alternatives to plpgsql
(3) llvmjit can speedup large computation queries a lot

plperl and plpython are almost free with the dependencies of contrib. llvmjit needs newer LLVM for BCI?
Comment 1 Dirk Mueller 2024-03-27 17:21:12 UTC 
Currently SLE BCI is defined to be a subset of SLES, so for (3) I understand that this functionality is also not avaiable on SLES without containers? Adding rmax to confirm. 

we can easily add -contrib into the container except that it has quite hefty size implications (pulls in python and perl interpreter and adds > 70 MB). I am generally fine with that as people who run databases also need storage for data so it shouldn't be a massive concern. 

for (2) I'm less certain what you're referring to. what would need to be done to enable that? do you hhave an example dockerfile that you use to build "your" container?
Comment 2 Jörg Sonnenberger 2024-03-27 19:55:29 UTC 
Most PostgreSQL instances I'm using are server+contrib. plperl and plpython are almost free as the heavy dependencies are pulled in by contrib already, but I don't have a large stake in that. So far I'm using only PL/PGSQL for stored procedures and triggers.