Re: WIP: Faster Expression Processing v4

On 2017-03-15 16:07:14 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2017-03-15 15:41:22 -0400, Tom Lane wrote:
> >> Color me dubious. Which specific other places have you got in mind, and
> >> do they have expression trees at hand that would tell them which columns
> >> they really need to pull out?
>
> > I was thinking of execGrouping.c's execTuplesMatch(),
> > TupleHashTableHash() (and unequal, but doubt that matters
> > performancewise). There's also nodeHash.c's ExecHashGetValue(), but I
> > think that'd possibly better fixed differently.
>
> The execGrouping.c functions don't have access to an expression tree
> instructing them which columns to pull out of the tuple, so I fail to see
> how get_last_attnums() would be of any use to them.

I presume most of the callers do. We'd have to change the API somewhat,
unless we just have a small loop in execTuplesMatch() determining the
biggest column index (which might be worthwhile / acceptable).
TupleHashTableHash() should be able to have that pre-computed in
BuildTupleHashTable(). Might be more viable to go that way.

> As for ExecHashGetHashValue, it's most likely going to be working from
> virtual tuples passed up to the join, which won't benefit from
> predetermination of the last column to be accessed. The
> tuple-deconstruction would have happened while projecting in the scan
> node below.

I think the physical tuple stuff commonly thwarts that argument? On
master for tpch's Q5 you can e.g. see the following profile (master):

+ 29.38% postgres postgres [.] ExecScanHashBucket
+ 16.72% postgres postgres [.] slot_getattr
+ 5.51% postgres postgres [.] heap_getnext
- 5.50% postgres postgres [.] slot_deform_tuple
- 98.07% slot_deform_tuple
- 85.98% slot_getattr
- 96.59% ExecHashGetHashValue
- ExecHashJoin
- ExecProcNode
+ 85.12% ExecHashJoin
+ 14.88% MultiExecHash
+ 3.41% ExecMakeFunctionResultNoSets
+ 14.02% slot_getsomeattrs
+ 1.58% ExecEvalScalarVarFast

I.e. nearly all calls for slot_deform_tuple are from slot_getattrs in
ExecHashGetHashValue(). And nearly all the time in slot_getattr is
spent on code only executed for actual tuples:

│ if (tuple == NULL) /* internal error */
0.18 │ test %rax,%rax
│ ↓ je 223
│ *
│ * (We have to check this separately because of various inheritance and
│ * table-alteration scenarios: the tuple could be either longer or shorter
│ * than the tupdesc.)
│ */
│ tup = tuple->t_data;
0.47 │ mov 0x10(%rax),%rsi
│ if (attnum > HeapTupleHeaderGetNatts(tup))
75.42 │ movzwl 0x12(%rsi),%eax
0.70 │ and $0x7ff,%eax
0.47 │ cmp %eax,%ebx
│ ↓ jg e8

- Andres