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

portalcmds.c

Blame
    • Tom Lane's avatar
      ba420024
      Revise handling of dropped columns in JOIN alias lists to avoid a · ba420024
      Tom Lane authored
      performance problem pointed out by phil@vodafone: to wit, we were
      spending O(N^2) time to check dropped-ness in an N-deep join tree,
      even in the case where the tree was freshly constructed and couldn't
      possibly mention any dropped columns.  Instead of recursing in
      get_rte_attribute_is_dropped(), change the data structure definition:
      the joinaliasvars list of a JOIN RTE must have a NULL Const instead
      of a Var at any position that references a now-dropped column.  This
      costs nothing during normal parse-rewrite-plan path, and instead we
      have a linear-time update to make when loading a stored rule that
      might contain now-dropped columns.  While at it, move the responsibility
      for acquring locks on relations referenced by rules into this separate
      function (which I therefore chose to call AcquireRewriteLocks).
      This saves effort --- namely, duplicated lock grabs in parser and rewriter
      --- in the normal path at a cost of one extra non-locked heap_open()
      in the stored-rule path; seems a good tradeoff.  A fringe benefit is
      that it is now *much* clearer that we acquire lock on relations referenced
      in rules before we make any rewriter decisions based on their properties.
      (I don't know of any bug of that ilk, but it wasn't exactly clear before.)
      ba420024
      History
      Revise handling of dropped columns in JOIN alias lists to avoid a
      Tom Lane authored
      performance problem pointed out by phil@vodafone: to wit, we were
      spending O(N^2) time to check dropped-ness in an N-deep join tree,
      even in the case where the tree was freshly constructed and couldn't
      possibly mention any dropped columns.  Instead of recursing in
      get_rte_attribute_is_dropped(), change the data structure definition:
      the joinaliasvars list of a JOIN RTE must have a NULL Const instead
      of a Var at any position that references a now-dropped column.  This
      costs nothing during normal parse-rewrite-plan path, and instead we
      have a linear-time update to make when loading a stored rule that
      might contain now-dropped columns.  While at it, move the responsibility
      for acquring locks on relations referenced by rules into this separate
      function (which I therefore chose to call AcquireRewriteLocks).
      This saves effort --- namely, duplicated lock grabs in parser and rewriter
      --- in the normal path at a cost of one extra non-locked heap_open()
      in the stored-rule path; seems a good tradeoff.  A fringe benefit is
      that it is now *much* clearer that we acquire lock on relations referenced
      in rules before we make any rewriter decisions based on their properties.
      (I don't know of any bug of that ilk, but it wasn't exactly clear before.)