colbuilder: disable wrapping of changefeed processors

[yuzefovich]

The root of the problem is that Columnarizer has buffering behavior -
in 20.1 it will be hanging until coldata.BatchSize() (1024 by default)
rows are emitted by the changefeed. On 20.2 and master due to dynamic
batch size behavior it will still be hanging but in a slightly
different manner.

This is less of a problem on 20.2 and the current master because the
vectorized engine will not be used for the changefeed DistSQL flow since
the vectorized row count threshold is never met for it (the estimated
row count for the plan is 0, so unless a user does
SET vectorize_row_count_threshold=0; or
SET vectorize=experimental_always;, we will always use row-by-row
engine). In 20.1 the meaning of vectorize=on was different - we never
looked at the threshold and used the vectorized engine if it was
supported.

In order to fix this issue we simply refuse to wrap the changefeed
processors, so the row-by-row engine will be always used for changefeed
flows.

Fixes: #55605.

Release note (bug fix): The current implementation of changefeeds is
incompatible with the vectorized engine, so whenever the latter is being
used to run the former, it could hang indefinitely. This is now fixed.
Namely, on 20.2 releases this could happen if the user runs
SET vectorize_row_count_threshold=0;, and on 20.1 releases - if the
user runs SET vectorize=on.

[cockroach-teamcity]

This change is 

[yuzefovich]

I think this PR fixes the issue for the time being because there is no benefit in planning a vectorized flow for changefeeds (we're simply adding a pair of Columnarizer - Materializer on top of ChangeFrontier) and I doubt we'll be vectorizing the changefeed processors any time soon (if ever).

[yuzefovich]

Interestingly, I prototyped making a columnarizer to have two modes of operation (either "buffering" or "streaming") here, and I hit an issue with clearing up memory monitoring infra (similar to #55408) which appears to be some kind of a race (a guess based on a quick debugging session). I think it's worth getting to the bottom of that.

[asubiotto]

Thanks for investigating. Can you add a test or modify an existing test that would fail with the existing behavior?

This is less of a problem on 20.2 and the current master because the
vectorized engine will not be used for the changefeed DistSQL flow since
the vectorized row count threshold is never met for it (the estimated
row count for the plan is 0

Is this always true?

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @asubiotto)

[asubiotto]

This likely needs a backport for all versions that have a vectorized setting

[yuzefovich]

Added a test.

Is this always true?

Yes, because we create a physical plan manually in

cockroach/pkg/ccl/changefeedccl/changefeed_dist.go

Lines 160 to 170 in 3e3aaf3

	p := sql.MakePhysicalPlan(gatewayNodeID)
	p.AddNoInputStage(corePlacement, execinfrapb.PostProcessSpec{}, changefeedResultTypes, execinfrapb.Ordering{})
	p.AddSingleGroupStage(
	gatewayNodeID,
	execinfrapb.ProcessorCoreUnion{ChangeFrontier: &changeFrontierSpec},
	execinfrapb.PostProcessSpec{},
	changefeedResultTypes,
	)
	p.PlanToStreamColMap = []int{1, 2, 3}
	dsp.FinalizePlan(planCtx, &p)

and we don't update MaxEstimatedRowCount field before running the plan, so it always remains at 0.

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @miretskiy)

[asubiotto]

Reviewed 2 of 2 files at r1.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @miretskiy)

[yuzefovich]

TFTR!

bors r+

[craig]

Build succeeded:

• GitHub CI (Cockroach)