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

explain.h

  • Tom Lane's avatar
    b9527e98
    First phase of plan-invalidation project: create a plan cache management · b9527e98
    Tom Lane authored
    module and teach PREPARE and protocol-level prepared statements to use it.
    In service of this, rearrange utility-statement processing so that parse
    analysis does not assume table schemas can't change before execution for
    utility statements (necessary because we don't attempt to re-acquire locks
    for utility statements when reusing a stored plan).  This requires some
    refactoring of the ProcessUtility API, but it ends up cleaner anyway,
    for instance we can get rid of the QueryContext global.
    
    Still to do: fix up SPI and related code to use the plan cache; I'm tempted to
    try to make SQL functions use it too.  Also, there are at least some aspects
    of system state that we want to ensure remain the same during a replan as in
    the original processing; search_path certainly ought to behave that way for
    instance, and perhaps there are others.
    b9527e98
    History
    First phase of plan-invalidation project: create a plan cache management
    Tom Lane authored
    module and teach PREPARE and protocol-level prepared statements to use it.
    In service of this, rearrange utility-statement processing so that parse
    analysis does not assume table schemas can't change before execution for
    utility statements (necessary because we don't attempt to re-acquire locks
    for utility statements when reusing a stored plan).  This requires some
    refactoring of the ProcessUtility API, but it ends up cleaner anyway,
    for instance we can get rid of the QueryContext global.
    
    Still to do: fix up SPI and related code to use the plan cache; I'm tempted to
    try to make SQL functions use it too.  Also, there are at least some aspects
    of system state that we want to ensure remain the same during a replan as in
    the original processing; search_path certainly ought to behave that way for
    instance, and perhaps there are others.