sql: make memo.IsStale more efficient (~1.5% cpu)

[nvanbenschoten]

In a high-throughput, write-heavy workload (kv0/2kb), we see that 11.1% of heap allocations come from under a call to memo.(*Memo).IsStale.

This feels very expensive. A reading of the code reveals that many of these allocations come from:

• stack variables escaping to the heap when passed to function signatures that accept pointer arguments
• non-pointer objects being boxed into interfaces
• closures being passed to interfaces, causing all of their closed over variables to escape to the heap

heap_profile.pb.gz

This code is on the hot path of query execution, so it deserves to be scrutinized for performance inefficiencies. Can we remove any of these heap allocations?

Jira issue: CRDB-29240

[msirek]

I reduced some of the heap allocations here, but kv0/2KB performance strangely decreased.

[mgartner]

In another real-world workload, I've observed memo.IsStale be responsible for 2.4% of CPU time:

And 3.4% of allocations:

It seems like this is rather expensive just to merely determine if a memo can be reused or not.