The work_mem section is incorrect. The article says the configuration is per worker, but it's actually per operation which requires work_mem... any given worker can have multiple operations running in parallel. So actually getting a good, but safe, value is more sensitive than the article suggests.<p><a href="https://www.postgresql.org/docs/9.5/static/runtime-config-resource.html#GUC-WORK-MEM" rel="nofollow">https://www.postgresql.org/docs/9.5/static/runtime-config-re...</a><p><i>work_mem (integer)<p>Specifies the amount of memory to be used by internal sort operations and hash tables before writing to temporary disk files. The value defaults to four megabytes (4MB). Note that for a complex query, several sort or hash operations might be running in parallel; each operation will be allowed to use as much memory as this value specifies before it starts to write data into temporary files. Also, several running sessions could be doing such operations concurrently. Therefore, the total memory used could be many times the value of work_mem; it is necessary to keep this fact in mind when choosing the value. Sort operations are used for ORDER BY, DISTINCT, and merge joins. Hash tables are used in hash joins, hash-based aggregation, and hash-based processing of IN subqueries.</i>
I recommend following Christophe Pettus - PostgreSQL Proficiency for Python People - PyCon 2016 video for postgresql basics and optimization<p><a href="https://www.youtube.com/watch?v=knUitQQnpJo" rel="nofollow">https://www.youtube.com/watch?v=knUitQQnpJo</a>
I'm currently reading "Designing Data-Intensive Applications" by Martin Kleppman and it has an interesting chapter on database storage engines, including PostgreSQL (e.g. B-trees chapter). I would definitely recommend if you'd like a high level overview of how things work under the hood (it's a good mix of theory and practice). It also helps understanding why and when optimisations work.