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

execGrouping.c

Blame
    • Andres Freund's avatar
      2ce9bca3
      jit: Re-allow JIT compilation of execGrouping.c hashtable comparisons. · 2ce9bca3
      Andres Freund authored
      In the course of 5567d12c, 356687bd and 317ffdfe, I changed
      BuildTupleHashTable[Ext]'s call to ExecBuildGroupingEqual to not pass
      in the parent node, but NULL. Which in turn prevents the tuple
      equality comparator from being JIT compiled.  While that fixes
      bug #15486, it is not actually necessary after all of the above commits,
      as we don't re-build the comparator when using the new
      BuildTupleHashTableExt() interface (as the content of the hashtable
      are reset, but the TupleHashTable itself is not).
      
      Therefore re-allow jit compilation for callers that use
      BuildTupleHashTableExt with a separate context for "metadata" and
      content.
      
      As in the previous commit, there's ongoing work to make this easier to
      test to prevent such regressions in the future, but that
      infrastructure is not going to be backpatchable.
      
      The performance impact of not JIT compiling hashtable equality
      comparators can be substantial e.g. for aggregation queries that
      aggregate a lot of input rows to few output rows (when there are a lot
      of output groups, there will be fewer comparisons).
      
      Author: Andres Freund
      Discussion: https://postgr.es/m/20190927072053.njf6prdl3vb7y7qb@alap3.anarazel.de
      Backpatch: 11, just as 5567d12c
      2ce9bca3
      History
      jit: Re-allow JIT compilation of execGrouping.c hashtable comparisons.
      Andres Freund authored
      In the course of 5567d12c, 356687bd and 317ffdfe, I changed
      BuildTupleHashTable[Ext]'s call to ExecBuildGroupingEqual to not pass
      in the parent node, but NULL. Which in turn prevents the tuple
      equality comparator from being JIT compiled.  While that fixes
      bug #15486, it is not actually necessary after all of the above commits,
      as we don't re-build the comparator when using the new
      BuildTupleHashTableExt() interface (as the content of the hashtable
      are reset, but the TupleHashTable itself is not).
      
      Therefore re-allow jit compilation for callers that use
      BuildTupleHashTableExt with a separate context for "metadata" and
      content.
      
      As in the previous commit, there's ongoing work to make this easier to
      test to prevent such regressions in the future, but that
      infrastructure is not going to be backpatchable.
      
      The performance impact of not JIT compiling hashtable equality
      comparators can be substantial e.g. for aggregation queries that
      aggregate a lot of input rows to few output rows (when there are a lot
      of output groups, there will be fewer comparisons).
      
      Author: Andres Freund
      Discussion: https://postgr.es/m/20190927072053.njf6prdl3vb7y7qb@alap3.anarazel.de
      Backpatch: 11, just as 5567d12c