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.
Thank you, that was amazing. I work in oracle and PG SQL a lot at work, but I never would have dared enter the source code. Mental barrier, broken through.
About select vs scan: sql's select is functionally a map - it's a transform, it has no searching semantics. Select and scanning are not strongly related, except that selection can influence how wide a data stream you need to scan is.
9 comments
[ 2.7 ms ] story [ 31.3 ms ] threadI'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.
I've never quite understood the My Little Pony craze, but that's some high quality documentation.
Amateur hour with amateur shell configuration that does not differentiate between directories and files.