Not a deep dive into pgsql source, but it does show some of the informative comments in the code. The author points out how well organized the source is, and t

Not a deep dive into pgsql source, but it does show some of the informative comments in the code. The author points out how well organized the source is, and the naming consistency in the sections shown makes it easy to follow the programmers' intentions. I've used pgsql for a long time, since 1998, and while far from a SQL expert, the database has always worked well for me. I attribute that to the extremely high quality of documentation, not only in the source, but also for users. It's rare to find comprehensive documentation suitable for both neophytes and experts, serving as both beginner's guide and technical reference manual. The project deserves high accolades for this accomplishment. I wish other projects would follow PostgresQL's example. Some team out there should research the hypothesis that there's a correlation between software success/performance and the quality of its user/developer documentation. For a long time it's been my hunch there's a strong effect of this nature. Measuring the parameters is probably the hard part. As it is I use the idea as a guide in selecting tools, libraries, etc. As a rule, if the documentation is a mess or non-existent, the software will be incomplete, full of bugs or soon abandoned. IOW, the better the documentation, the more valuable the software.