Chunk column reuse

[tiancaiamao]

Enhancement

Currently, TiDB allocation cause too much burden to the Go GC, and slow down the program.

Prepare plan cache can help a lot to reduce the allocation, unfortunately we still can not take full advantage of it.
I reported this issue #26868 in the past.
@qw4990 and @Reminiscent is handling it and we wish to make it GA soon.

Prepare plan cache ranks top1 in reducing the allocation.
So after that, I find chunk allocation also accounts a lot.

If we can reuse the chunk column, it may reduce the object allocation.

Chunk columns are feasible for reuse, as you can see they are fix sized depending on the field type, and there is no complex structure in it, only slice of bytes:

tidb/util/chunk/column.go

Lines 63 to 84 in 955274f

	type Column struct {
	length int
	nullBitmap []byte // bit 0 is null, 1 is not null
	offsets []int64 // used for varLen column. Row i starts from data[offsets[i]]
	data []byte
	elemBuf []byte
	}
	// NewColumn creates a new column with the specific type and capacity.
	func NewColumn(ft *types.FieldType, cap int) *Column {
	return newColumn(getFixedLen(ft), cap)
	}
	func newColumn(typeSize, cap int) *Column {
	var col *Column
	if typeSize == varElemLen {
	col = newVarLenColumn(cap)
	} else {
	col = newFixedLenColumn(typeSize, cap)
	}
	return col
	}

[tiancaiamao]

@Defined2014

[Defined2014]

We have localColumnPool in expression/builtin_vectorized.go. So when enabled tidb_enable_vectorized_expression, it will reuse column chunk.

tidb/expression/builtin_vectorized.go

Lines 36 to 73 in cc524af

	type localColumnPool struct {
	sync.Pool
	}
	func newLocalColumnPool() *localColumnPool {
	newColumn := chunk.NewColumn(types.NewFieldType(mysql.TypeLonglong), chunk.InitialCapacity)
	return &localColumnPool{
	sync.Pool{
	New: func() interface{} {
	return newColumn.CopyConstruct(nil)
	},
	},
	}
	}
	var globalColumnAllocator = newLocalColumnPool()
	// GetColumn allocates a column. The allocator is not responsible for initializing the column, so please initialize it before using.
	func GetColumn(_ types.EvalType, _ int) (*chunk.Column, error) {
	return globalColumnAllocator.get()
	}
	// PutColumn releases a column buffer.
	func PutColumn(buf *chunk.Column) {
	globalColumnAllocator.put(buf)
	}
	func (r *localColumnPool) get() (*chunk.Column, error) {
	col, ok := r.Pool.Get().(*chunk.Column)
	if !ok {
	return nil, errors.New("unexpected object in localColumnPool")
	}
	return col, nil
	}
	func (r *localColumnPool) put(col *chunk.Column) {
	r.Pool.Put(col)
	}

The implemention use sync.Pool to cache chunk column which will be recycled in 2 GC duration. It is introduced by #26078, not sure included in your test or not.

I'm not sure we need a true mempool for chunk column or not, because I can't reproduce high usage in chunk column right now. @tiancaiamao

[tiancaiamao]

I guess it's for the OLAP query, and OLTP can't benefit from it. @Defined2014

[tiancaiamao]

I found the old picture, the motivation for this issue:

We already have the code localColumnPool in expression/builtin_vectorized.go,
but as you can see, it doesn't eliminate the chunk allocation.

[tiancaiamao]

I think maybe we can test the changes in the bank workload to verify it. @dbsid