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

tsquery_rewrite.c

Blame
    • Tom Lane's avatar
      23a27b03
      Widen query numbers-of-tuples-processed counters to uint64. · 23a27b03
      Tom Lane authored
      This patch widens SPI_processed, EState's es_processed field, PortalData's
      portalPos field, FuncCallContext's call_cntr and max_calls fields,
      ExecutorRun's count argument, PortalRunFetch's result, and the max number
      of rows in a SPITupleTable to uint64, and deals with (I hope) all the
      ensuing fallout.  Some of these values were declared uint32 before, and
      others "long".
      
      I also removed PortalData's posOverflow field, since that logic seems
      pretty useless given that portalPos is now always 64 bits.
      
      The user-visible results are that command tags for SELECT etc will
      correctly report tuple counts larger than 4G, as will plpgsql's GET
      GET DIAGNOSTICS ... ROW_COUNT command.  Queries processing more tuples
      than that are still not exactly the norm, but they're becoming more
      common.
      
      Most values associated with FETCH/MOVE distances, such as PortalRun's count
      argument and the count argument of most SPI functions that have one, remain
      declared as "long".  It's not clear whether it would be worth promoting
      those to int64; but it would definitely be a large dollop of additional
      API churn on top of this, and it would only help 32-bit platforms which
      seem relatively less likely to see any benefit.
      
      Andreas Scherbaum, reviewed by Christian Ullrich, additional hacking by me
      23a27b03
      History
      Widen query numbers-of-tuples-processed counters to uint64.
      Tom Lane authored
      This patch widens SPI_processed, EState's es_processed field, PortalData's
      portalPos field, FuncCallContext's call_cntr and max_calls fields,
      ExecutorRun's count argument, PortalRunFetch's result, and the max number
      of rows in a SPITupleTable to uint64, and deals with (I hope) all the
      ensuing fallout.  Some of these values were declared uint32 before, and
      others "long".
      
      I also removed PortalData's posOverflow field, since that logic seems
      pretty useless given that portalPos is now always 64 bits.
      
      The user-visible results are that command tags for SELECT etc will
      correctly report tuple counts larger than 4G, as will plpgsql's GET
      GET DIAGNOSTICS ... ROW_COUNT command.  Queries processing more tuples
      than that are still not exactly the norm, but they're becoming more
      common.
      
      Most values associated with FETCH/MOVE distances, such as PortalRun's count
      argument and the count argument of most SPI functions that have one, remain
      declared as "long".  It's not clear whether it would be worth promoting
      those to int64; but it would definitely be a large dollop of additional
      API churn on top of this, and it would only help 32-bit platforms which
      seem relatively less likely to see any benefit.
      
      Andreas Scherbaum, reviewed by Christian Ullrich, additional hacking by me