On Thu, Apr 21, 2016 at 08:37:54PM -0700, Peter Geoghegan wrote: > Documentation > ============= > > I think we can expand "21.6. Tablespaces" to describe the implications > of these new performance characteristics. I'd like to hear opinions on > how to approach that before proposing a patch, though. The basic > guidance should, IMV, be: > > * A temp tablespace with cheaper disks that have good sequential I/O > performance can speed up external sorts quite a lot. Probably not a > great idea to have many temp tablespaces. Use RAID0 instead, because > that performs better, and because it doesn't matter that temp files > are not recoverable if a disk is faulty. > > * More memory for sorting and hashing is often better in PostgreSQL > 9.6. Notably, the performance of hash joins that spill will tend to > degrade less predictably than the performance of sorts that spill as > less memory is made available. (Perhaps mention the number of external > sort passes?) > > * Increasing work_mem/maintenance_work_mem may fail to improve > performance only because sorts then become more I/O bound. When in > doubt, testing is advised. A balance may need to be found, if only to > avoid wasting memory.
This seems very detailed. I think we need much broader coverage of how the existing GUC variables affect performance before we could cover this. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
