På fredag 22. april 2016 kl. 14:56:33, skrev Robert Haas <robertmh...@gmail.com 
On Thu, Apr 21, 2016 at 7:20 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
 > Robert Haas <robertmh...@gmail.com> writes:
 >> On Thu, Apr 21, 2016 at 4:01 PM, Gavin Flower
 >> <gavinflo...@archidevsys.co.nz> wrote:
 >>> Why not 4?  As most processors now have at least 4 physical cores, & 
 >>> it be more likely to flush out race conditions.
 >> Because if we did that, then it's extremely likely that people would
 >> end up writing queries that are faster only if workers are present,
 >> and then not get any workers.
 > Is that because max_worker_processes is only 8 by default?  Maybe we
 > need to raise that, at least for beta purposes?

 I'm not really in favor of that.  I mean, almost all of our default
 settings are optimized for running PostgreSQL on, for example, a
 Raspberry Pi 2, so it would seem odd to suddenly swing the other
 direction and assume that there are more than 8 unused CPU cores.  It
 doesn't make sense to me to roll out settings in beta that we wouldn't
 be willing to release with if they work out.  That's why, honestly, I
 would prefer max_parallel_degree=1, which I think would be practical
 for many real-world deployments.  max_parallel_degree=2 is OK.  Beyond
 that, we're just setting people up to fail, I think.  Higher settings
 should probably only be used on substantial hardware, and not
 everybody has that.
Maybe it's time to ask the question if the settings should be optimized more 
for high-end HW and not som matchstick-box? I mean, most of the people I know 
who are responsible for databases run them on HW colser to high-end than 
low-end. I'm not sure why optimizing for low-end is such a great choice.
-- Andreas Joseph Krog


Reply via email to