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

FAQ

  • Clone with SSH
  • Clone with HTTPS
  • user avatar
    Tom Lane authored
    into an OR of equality comparisons, rather than x = ANY(ARRAY[...]), when there
    are Vars in the right-hand side.  This avoids a performance regression compared
    to pre-8.2 releases, in cases where the OR form can be optimized into scans
    of multiple indexes.  Limit the possible downside by preferring this form only
    when the list isn't very long (I set the cutoff at 32 elements, which is a
    bit arbitrary but in the right ballpark).  Per discussion with Jim Nasby.
    
    In passing, also make it try the OR form if it cannot select a common type
    for the array elements; we've seen a complaint or two about how the OR form
    worked for such cases and ARRAY doesn't.
    ddbe8dca
    History
    Name Last commit Last update
    ..