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
    Tom Lane authored
    node now does its own grouping of the input rows, and has no need for a
    preceding GROUP node in the plan pipeline.  This allows elimination of
    the misnamed tuplePerGroup option for GROUP, and actually saves more code
    in nodeGroup.c than it costs in nodeAgg.c, as well as being presumably
    faster.  Restructure the API of query_planner so that we do not commit to
    using a sorted or unsorted plan in query_planner; instead grouping_planner
    makes the decision.  (Right now it isn't any smarter than query_planner
    was, but that will change as soon as it has the option to select a hash-
    based aggregation step.)  Despite all the hackery, no initdb needed since
    only in-memory node types changed.
    f6dba10e
    History
    Name Last commit Last update