On Fri, Jan 9, 2015 at 4:26 PM, Steve Crawford <scrawford@xxxxxxxxxxxxxxxxxxxx> wrote: > New hardware is quite different. 2x10-core E5-2660v3 @2.6GHz, 128GB > DDR4-2133 RAM and 800GB Intel DC P3700 NVMe PCIe SSD. In essence, the > dataset will fit in RAM and will be backed by exceedingly fast storage. > > This new machine is very different than any we've had before so any current > thinking on optimization would be appreciated. Do I leave indexes as is and > evaluate which ones to drop later? Any recommendations on distribution > and/or kernels (and kernel tuning)? PostgreSQL tuning starting points? > Whatever comes to mind. That's always a good idea (don't optimize prematurely). Still, you may want to tweak random_page_cost to bring it closer to seq's cost to get plans that are more suited to your exceedingly fast storage (not to mention effective_cache_size, which should be a given). You'll most likely be CPU-bound, so optimization will involve tweaking data types. Since you mention lots of writes, I'd imagine you will also want to tweak shared_buffers and checkpoint_segments to adapt it to your NVM card's buffering, and as with everything new, test or reasearch into the card's crash behavior (ie: what happens when you pull the plug). I've heard of SSD storage solutions that got hopelessly corrupted with pull the plug tests, so be careful with that, but you do certainly want to know how this card would behave in a power outage. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
