postgres-operator VS pg_hint_plan

yes, precisely. It's UI part that's broken, which cannot list snapshots. Issue is here, no fix since 2020, sadly: https://github.com/zalando/postgres-operator/issues/937

I personally like the Zalando operator better, you can add databases and users by updating the CRD, feature parity between the two on HA is pretty good

https://github.com/zalando/postgres-operator

one of the solutions which made it pretty simple for us to run postgresql in a ha environment (mostly in k8s, but works standalone as well) is zalandos patroni: https://github.com/zalando/patroni it's really solid and worked for us for a few years already.

or for k8s their operator: https://github.com/zalando/postgres-operator (docker image: https://github.com/zalando/spilo) we've also tried other operators which were easier to get started, but they failed miserably (crunchyrolls operator is basically based on the zalando one)

git clone https://github.com/zalando/postgres-operator.git cd postgres-operator

Zalando / Postgres-Operator

Somewhere between here and here i found out about that.

Here's an example of using the PostgreSQL Operator to deploy a high availability PostgreSQL cluster in Kubernetes. In this example, I'll be using the PostgreSQL Operator from Zalando [https://github.com/zalando/postgres-operator] to deploy a PostgreSQL cluster with two nodes.

Here's the operator for a postgres cluster: https://github.com/zalando/postgres-operator

And that repo you linked to has 1846 issues, 161 open. Which doesn't seem extraordinary based on my limited exposure to k8s.

Another example: https://github.com/zalando/postgres-operator/issues with 445 open issues. Why?

Maybe I'm wrong and this is all a good sign of progress, but my impression is that the entire k8s ecosystem is held together with reused duct tape.

Okay so it isn't entirely clear to me, can the pg_hint_plan extension (linked in the OP) do the simple thing where we specify, for each table, which index to use?

I can't find it here

https://github.com/ossc-db/pg_hint_plan/blob/master/docs/hin...

Because, the mssql WITH(INDEX()) is simple and intuitive. This hint table stuff seems complicated, and it's unclear to me if they can do the simple thing

pg_hint_plan —— Give PostgreSQL ability to manually force some decisions in execution plans. https://github.com/ossc-db/pg_hint_plan

I really wish the PostgreSQL core team would acknowledge that their stance on that hurts more than helps. Even Oracle with decades of engineering behind it doesn't get execution plans correct 100% of the time and provides a way to tune query execution via hints.

However, TIL that https://github.com/ossc-db/pg_hint_plan exists so that will probably become a standard thing I deploy.

With PostgreSQL, the extension to do it, pg_hint_plan is really good, but not widely used because not included in the core, not even in contrib. The consequence is that people install it only when needing it, without the time to learn hot to hint properly, may think that "my hint is not used" and give up.

cat > Dockerfile <<'DOCKERFILE' # install pg_hint_plan from rpm FROM docker.io/postgres:14 ADD https://github.com/ossc-db/pg_hint_plan/releases/download/REL14_1_4_0/pg_hint_plan14-1.4-1.el8.x86_64.rpm . RUN apt-get update -y ; apt-get install -y alien wget ; alien ./pg_hint_plan*.rpm ; dpkg -i pg-hint-plan*.deb # copy the minimal files to a postgres image FROM docker.io/postgres:14 COPY --from=0 /usr/pgsql-14/share/extension/pg_hint_plan.control /usr/share/postgresql/14/extension COPY --from=0 /usr/pgsql-14/share/extension/pg_hint_plan--1.4.sql /usr/share/postgresql/14/extension COPY --from=0 /usr/pgsql-14/lib/pg_hint_plan.so /usr/pgsql-14/lib/pg_hint_plan.so /usr/lib/postgresql/14/lib ENV PGPASSWORD=postgres CMD ["postgres","-c","shared_preload_libraries=pg_hint_plan,pg_stat_statements"] DOCKERFILE docker build -t pachot/pg_hint_plan --platform=linux/amd64 . docker push pachot/pg_hint_plan

there is a maintained index hint extension: https://github.com/ossc-db/pg_hint_plan - at least as far as 13 (and likely 14).

if we're going to talk about index functionality that would be good and effective for Postgres, an index across all partitioned tables (both normal and unique) would be very much welcomed.

the problem is finding someone to maintain it for life.