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

7 points by DumBthInker007 1 year ago | 14 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!

znpy 1 year 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...

DumBthInker007 1 year ago | |

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

znpy 1 year ago | | |

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

cssanchez 1 year 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.

DumBthInker007 1 year ago | |

Thanks for sharing.

WilcoKruijer 1 year 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.

dapperdrake 1 year 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.

DumBthInker007 1 year ago | |

Thanks for the reply,will surely look into it.

I_am_tiberius 1 year 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.

hyperman1 1 year ago |

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

DumBthInker007 1 year 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:).

hyperman1 1 year ago | | |

What can I say, except thank you very much.

dapperdrake 1 year 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"?