Hacker News Reader

Hacker News

Comment by tiffanyh | Hacker News Reader

Full thread

tiffanyh

Robert Haas is just amazing.

For just Postgres, he has completed:

- No more full table vacuums

- Parallel Sequential Scan

- Major memory improvements for NUMA

- Major improvements for large multi-core systems

My only concern is that it appears that Robert is the only person tackling big/major improvements for Postgres.

I might be wrong, but that's the perception. I hope this isn't the case and other are also tackling big improvements to Postgres.

View on HN

In this post, Haas explicitly credits Masahiko Sawada for most of the work on this feature. Haas definitely does lots of work, but there are other significant contributors as well.

While Robert certainly does a huge amount of work, this is a bit incorrect perception of how contributing to PostgreSQL works. There are ~20 developers responsible for final reviews and committing changes coming from other contributors, and Robert is one of them.

That's of course a lot of work and requires a lot of experience, but it may skew the perception a bit.

I often hear "there are only 20 people working on PostgreSQL" because the people don't realize that the guy who committed it may not be the one who implemented it.

For example while Robert did a lot of work on the parallel stuff, large parts it were written by Amit Kapila, but he's not a committer so Robert is the one whose name is on the git commit. The actual authors/reviewers and so on are tracked in the commit message, but people often miss that.

I sometimes hear "But there are only 20 people working on PostgreSQL!" because people don't realize that (and tools like ohloh/openhub/... make this mistake too).

The actual author can be correctly attributed in git by using the --author flag at commit time. For example, git commit --author "My Friend <friend@example.com>". The resulting git commit will show the committer as committer and the author as author, correctly providing attribution in changelogs. :)

That doesn't really work well, because frequently for more complex patches there's more than one significant author. So we end up crediting them in the text of the commit message instead. We're slowly converging of using a bit more standardized descriptions of who authored a commit, but so far it's not easily machine parsable :(

I think the idea is that you use a topic branch and each incremental piece is authored by the individual that authored it. Then the branch is merged in when the feature is done. If someone helps substantially at the atomic commit level, then they get greetz in the commit message; the person with 50%+ responsibility should get the author flag. If commits are in small enough units, that should be pretty doable and all code remains properly attributed.

I do sympathize that not enough attention has been given to this, though, and there are probably people who don't want to follow the branching model. Would be nice if you could identify multiple authors in git. Here's a bug discussing that: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451880

That model leaves you with an incredibly unusable history. So I think the chances of going there are zero.

It also doesn't work because a patch if sometimes reworked by multiple people - either the committer himself, or a co-author of the patch series.

That isn't the case. If you are interested, I would suggest joining the Postgres hackers mailing list. Reading that will give a better picture of what is happening and who is doing the happening.

> Postgres hackers mailing list

Link on Gmane:

http://news.gmane.org/gmane.comp.db.postgresql.devel.general

When we talk about "big" patches, it's probably worth examining full change sets. The changes for removing vacuuming are here [1]. Compare that to those for the "biggest" 9.5 feature, upsert [2] (by Peter Geoghegan) and you can see that there's probably at least a full order of magnitude difference in effort there.

That said, Postgres probably does have a problem in that there are too few people writing these major patches, but that number is greater than one.

[1] http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;...

[2] http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;...

> Postgres probably does have a problem in that there are too few people writing these major patches

I don't think that's the major problem. That is having enough experienced people with enough bandwidth, to make those patches suitable for integration.

Robert is amazing, I 100% agree. Not only has he done a lot of great things himself, but he's helped with other people's work (including mine) as well.

But lots of others do great work, as well. Some of it very big and ambitious, some of it is more humble and incremental.

Reply on news.ycombinator.com