opt: add cost for executing geo functions in filters

[madelynnblue]

Geo costing is now the only function that multiplies its row count by
the filters cost. The other JOINs and SELECT will be added in another
PR since it is a more complicated change due to some plans changing,
which must come with some justification.

Fixes #48214

Release note: None

[cockroach-teamcity]

This change is 

[madelynnblue]

This PR collects all of the geo-related changes from #49074 into a single commit. That other PR will be closed and the non-geo changes can be done at some future time. They were getting hairy and needed some more data-backed justification.

[RaduBerinde]

(but wait for an ok from @rytaft too)

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @mjibson and @rytaft)

---

pkg/sql/opt/xform/coster.go, line 540 at r1 (raw file):

	cost += memo.Cost(rowsProcessed) * perRowCost

	// We don't add the result of computeFiltersCost to perRowCost because

[nit] Maybe explain why we're doing 1+ (we want a "set up cost" even for cases with very tiny row count).

---

pkg/sql/opt/xform/coster.go, line 583 at r1 (raw file):

		// Add a constant "setup" cost per ON condition to account for the fact that
		// the rowsProcessed estimate alone cannot effectively discriminate between
		// plans when RowCount is too small.

[nit] Add a TODO here that we should perhaps separate the one-time and the per-row cost and return them separately, to make the interface nicer. Currently this clashes conceptually with the (1+rowsProcessed) thing we're adding.

[rytaft]

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

---

pkg/sql/opt/xform/coster.go, line 493 at r1 (raw file):

	// Take into account that the "internal" row count is higher, according to
	// the selectivities of the conditions. In particular, we need to ignore
	// left-over conditions that are not selective.

[nit] doesn't actually matter whether or not they are selective -- we still need to process the same number of rows. I'd say "we need to ignore the conditions that don't affect the number of rows processed".

[madelynnblue]

Reviewable status: complete! 0 of 0 LGTMs obtained (and 2 stale) (waiting on @RaduBerinde and @rytaft)

---

pkg/sql/opt/xform/coster.go, line 493 at r1 (raw file):

Previously, rytaft (Rebecca Taft) wrote…

[nit] doesn't actually matter whether or not they are selective -- we still need to process the same number of rows. I'd say "we need to ignore the conditions that don't affect the number of rows processed".

Thanks for the words. It's taking a while for me to get it.

---

pkg/sql/opt/xform/coster.go, line 540 at r1 (raw file):

Previously, RaduBerinde wrote…

[nit] Maybe explain why we're doing 1+ (we want a "set up cost" even for cases with very tiny row count).

The 1+ is documented as a setup cost in the comment for computeFiltersCost. Otherwise it'd be duplicated for each call of that function, which seems excessive.

[rytaft]

Reviewed 2 of 2 files at r2.
Reviewable status: complete! 0 of 0 LGTMs obtained (and 2 stale) (waiting on @RaduBerinde)

[rytaft]

---

pkg/sql/opt/xform/coster.go, line 493 at r1 (raw file):

Previously, mjibson (Matt Jibson) wrote…

Thanks for the words. It's taking a while for me to get it.

No worries! This stuff is definitely not obvious.

[madelynnblue]

bors r+

[craig]

Build failed (retrying...)

• GitHub CI (Cockroach)

[craig]

Build succeeded

• GitHub CI (Cockroach)