Ask HN: I'm a New PostgreSQL Hacker – What Problems Do You Face with Postgres?

7 pointsDumBthInker00710mo ago14 comments

Hi HN,

I'm a developer diving deep into PostgreSQL internals, aiming to contribute meaningfully to the project. I have a strong grasp of core components like the internal architecture, physical replication, WAL (Write-Ahead Logging), and buffer management. I'm now expanding into areas like logical replication, asynchronous I/O (AIO), the optimizer, and beyond.

To learn and grow as a Postgres hacker, I want to hear directly from you—PostgreSQL users—about the problems you face, big or small. These could be operational challenges, performance bottlenecks, confusing behaviors, missing features, or friction points in your workflows.

For me, it's a win-win: you get a contributor trying to tackle real problems, and I get to deepen my understanding by working on issues that matter in the real world. If a problem resonates with me, I’ll do my best to investigate, learn, and potentially create a patch to address it.

Thanks—and I look forward to hearing from you!

14 comments

znpy10mo ago

I'd like to see something like MySQL's Group Replication in PostgreSQL.

HA is still a wheel you have to re-invent yourself every time with PostgreSQL.

References for what i'm talking about:

- Group Replication: https://dev.mysql.com/doc/refman/8.4/en/group-replication.ht...

DumBthInker007OP10mo ago

thanks for the quick reply, will surely look into it.

znpy10mo ago

You're welcome. The bigger picture is probably this: https://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster...

1 more reply

cssanchez10mo ago

My experience with PG ended a few years ago. The thing that killed PG for me is the lack of collation for searches. I haven't tested since the last updates that mentioned something along these lines, so this may have improved.

PG for years relied on unaccent which is not a true solution as it requires manually storing two versions of a text (the original and the un-accented one) and handle indexes + searches manually for each field... Not to mention unaccent itself is an extension you have to install. Whereas collation is built-in and it just works by handling it all under the hood in SQL Server. This feature alone is worth switching databases for my use cases.

That and the updates being a royal pain.

DumBthInker007OP10mo ago

Thanks for sharing.

WilcoKruijer10mo ago

I’d like to see a true monotonic counter in Postgres. Serials can increment out of order when multiple transactions are active. We can obtain the WAL LSN, but it’s not related to the currently active transaction. I really like FoundationDB’s versionstamp, would be great to have that in Postgres.

dapperdrake10mo ago

How is a "true monotonic counter" supposed to interact with atomicity and isolation of transactions? Sounds like a global bottleneck.

Is uniqueness sufficient or is it really required to step through all integers without missing any?

EDIT: Missing primary keys in-between also bothers me, however, never found a decent solution for this at scale.

DumBthInker007OP10mo ago

Thanks for the reply,will surely look into it.

I_am_tiberius10mo ago

1. I'd like a native way to scale horizontally based on tenant ids without using citus. 2. array constraints (foreign keys) -> meaning that each item in the array references an id in another table.

hyperman110mo ago

Parallell insert. I can easily saturate a CPU with insert statements, with io very low.

DumBthInker007OP10mo ago

Hi thanks for the reply ,i guess there was some ongoing work for this and for some reason it didn't continued this is the thread https://www.postgresql.org/message-id/flat/CAJcOf-cXnB5cnMKq... if you are interested in, but for sure i will look into this(added to my list:).

hyperman110mo ago

What can I say, except thank you very much.

dapperdrake10mo ago

That seems like an unintuitive consequence. Saturating disk would have been obvious. But CPU?

Does anything about the INSERT pattern seem "special"? Or does it happen for many different "kinds of INSERT statements"?

j / k navigate · click thread line to collapse

Ask HN: I'm a New PostgreSQL Hacker – What Problems Do You Face with Postgres?

7 pointsDumBthInker00710mo ago14 comments

Hi HN,

Thanks—and I look forward to hearing from you!

14 comments

znpy10mo ago

I'd like to see something like MySQL's Group Replication in PostgreSQL.

HA is still a wheel you have to re-invent yourself every time with PostgreSQL.

References for what i'm talking about:

- Group Replication: https://dev.mysql.com/doc/refman/8.4/en/group-replication.ht...

DumBthInker007OP10mo ago

thanks for the quick reply, will surely look into it.

znpy10mo ago

You're welcome. The bigger picture is probably this: https://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster...

1 more reply

cssanchez10mo ago

That and the updates being a royal pain.

DumBthInker007OP10mo ago

Thanks for sharing.

WilcoKruijer10mo ago

dapperdrake10mo ago

How is a "true monotonic counter" supposed to interact with atomicity and isolation of transactions? Sounds like a global bottleneck.

Is uniqueness sufficient or is it really required to step through all integers without missing any?

EDIT: Missing primary keys in-between also bothers me, however, never found a decent solution for this at scale.

DumBthInker007OP10mo ago

Thanks for the reply,will surely look into it.

I_am_tiberius10mo ago

1. I'd like a native way to scale horizontally based on tenant ids without using citus. 2. array constraints (foreign keys) -> meaning that each item in the array references an id in another table.

hyperman110mo ago

Parallell insert. I can easily saturate a CPU with insert statements, with io very low.

DumBthInker007OP10mo ago

hyperman110mo ago

What can I say, except thank you very much.

dapperdrake10mo ago

That seems like an unintuitive consequence. Saturating disk would have been obvious. But CPU?

Does anything about the INSERT pattern seem "special"? Or does it happen for many different "kinds of INSERT statements"?

j / k navigate · click thread line to collapse