Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

postgres-lambda-diff

  • Clone with SSH
  • Clone with HTTPS
  • user avatar
    Robert Haas authored
    This new limit affects both the max_parallel_degree GUC and the
    parallel_degree reloption.  There may some day be a use case for using
    more than 1024 CPUs for a single query, but that's surely not the case
    right now.  Not only do not very many people have that many CPUs, but
    the code hasn't been tested at that kind of scale and is very unlikely
    to perform well, or even work at all, without a lot more work.  The
    issue addressed by commit 06bd458c is
    probably just one problem of many.
    
    The idea of a more reasonable limit here was suggested by Tom Lane;
    the value of 1024 was suggested by Amit Kapila.
    c7ea68ff
    History
    Name Last commit Last update