3 ms·

Robert Haas is just amazing. For just Postgres, he has completed: - No more full table vacuums - Parallel Sequential Scan - Major memory improvements for NU

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.

dhd415 11y ago
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.
rpedela 11y ago
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.
- egor83 11y ago
  > Postgres hackers mailing list Link on Gmane: http://news.gmane.org/gmane.comp.db.postgresql.devel.general http://news.gmane.org/gmane.comp.db.postgresql.devel.general
brandur 11y ago
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;h=fd31cd265138019dcccc9b5fe53043670898bc9f http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;... [2] http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=168d5805e4c08bed7b95d351bf097cff7c07dd65 http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;...
- anarazel 11y ago
  > 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.
jeffdavis 11y ago
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.
pgaddict 11y ago
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).
- cookiecaper 11y ago
  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. :)
  - anarazel 11y ago
    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 :(
    - cookiecaper 11y ago
      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 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451880

dhd415 11y ago

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.

rpedela 11y ago

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.

egor83 11y ago
> Postgres hackers mailing list Link on Gmane: http://news.gmane.org/gmane.comp.db.postgresql.devel.general http://news.gmane.org/gmane.comp.db.postgresql.devel.general

brandur 11y ago

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;h=fd31cd265138019dcccc9b5fe53043670898bc9f http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;... [2] http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=168d5805e4c08bed7b95d351bf097cff7c07dd65 http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;...

anarazel 11y ago
> 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.

jeffdavis 11y ago

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.

pgaddict 11y ago

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).

cookiecaper 11y ago
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. :)
- anarazel 11y ago
  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 :(
  - cookiecaper 11y ago
    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 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451880