sql/pgwire: consider implementing opcode style execution for forming pgwire messages

[yuzefovich]

Extracted from here.

pkg/sql/pgwire/conn.go, line 1282 at r11 (raw file):

		c.msgBuilder.initMsg(pgwirebase.ServerMsgDataRow)
		c.msgBuilder.putInt16(width)
		for colIdx, col := range vecs {

Idea for later: this could be the perfect place for us to prototype the "opcode style" of execution, since it's such a simple, constrained codepath. I'm not even sure if it would help matters, but I know from profiles that the most expensive part of places like this where we revert to row-based execution is the type switching.

So, what if we made a simple little opcode runner, and pre-calculated the types that we will be running through over and over again on every row?

For example, at plantime, we'd run something like this:

opcodes = []
for i, type := types {
    fmtCode = formatCodes[i]
    opcodes = append(opcodes, getOpcode(type, fmtCode)
}

An "opcode" would be something like EncodeBinaryInt32 or EncodeTextDate.

Then, at runtime (aka right here), we'd run:

for i := 0; i < n; i++ {
    // get rowidx
    for _, opCode := range opCodes {
        switch opCode {
            case EncodeBinaryInt32:
                ...
        }
    }
}

Then again maybe we'd gain exactly nothing here - we'd be replacing a type switch with an int switch, but we'd keep the interface-to-ptr cast...

Maybe the true way to make all of this better would be to use more unsafe.Ptr stuff to avoid the expensive, checked interface type lookup and cast.

Jira issue: CRDB-7814

[github-actions]

We have marked this issue as stale because it has been inactive for
18 months. If this issue is still relevant, removing the stale label
or adding a comment will keep it active. Otherwise, we'll close it in
10 days to keep the issue queue tidy. Thank you for your contribution
to CockroachDB!