Add in docs to describe window performance

[revans2]

Right now this is a document only change, but I really would be interested to hear from others if we think we should include some configs to allow users to selectively disable window operations. The problem is that the slowness is based off of the window size, and this is data dependent, as you can see from #3021. That means we cannot detect ahead of time if we are going to see slowness. I will file a follow on issue/epic for optimizations we know we can do.

[jlowe]

Docs look good to me.

I really would be interested to hear from others if we think we should include some configs to allow users to selectively disable window operations.

It might be handy in practice to have window configs to control the various window types. That way if a user discovers a performance problem or bug in windowing then they can easily work around that case without forcing all window operations off the GPU. If it's easy I say let's do it, but if it's quite a bit of work then maybe we wait until we more clearly see the need. It seems to come down to how likely do we think a query will have multiple types of windows where disabling one window type but leaving another enabled is better than blanket disabling GpuWindowExec.

[jlowe]

build

[revans2]

@jlowe I am trying to figure out what the configs should look like. I can make them specific to performance optimizations and small. Like

• spark.rapids.sql.window.unoptimizedUnboundedToUnbounded.enabled - Which would fall back to the CPU for unbounded to unbounded aggregations that are not constant time operations aka COUNT(1)
• spark.rapids.sql.window.unoptimizedUnboundedToBounded.enabled - Which would fall back to the CPU for unbounded to bounded aggregations that are not optimized to use scan/group by scan, or something else in the future when we can support those.

But if I try to make something more generic I would end up with a lot of configs (18 if I can count)

ROW/RANGE	PRECEDING	FOLLOWING
ROW	Unbounded	Unbounded
RANGE	Unbounded	Unbounded
ROW	Unbounded	Current Row
RANGE	Unbounded	Current Value
ROW	Unbounded	OTHER BOUNDED
RANGE	Unbounded	OTHER BOUNDED
ROW	Current Row	Unbounded
RANGE	Current Value	Unbounded
ROW	Current Row	Current Row
RANGE	Current Value	Current Value
ROW	Current Row	OTHER BOUNDED
RANGE	Current Value	OTHER BOUNDED
ROW	OTHER BOUNDED	Unbounded
RANGE	OTHER BOUNDED	Unbounded
ROW	OTHER BOUNDED	Current Row
RANGE	OTHER BOUNDED	Current Value
ROW	OTHER BOUNDED	OTHER BOUNDED
RANGE	OTHER BOUNDED	OTHER BOUNDED

And then the performance problems/bugs are likely to be specific to different aggregations, so it might end up being 18-ish configs per aggregation (SUM, MIN, MAX, COUNT, ROW_NUMBER, LEAD, LAG, ...) I am not sure that this is what we want either.

[revans2]

build

[jlowe]

I am not sure that this is what we want either.

Yeah so then I'm thinking maybe we hold off a bit until we get clearer guidance from real-world use as to what we really need.

[revans2]

Had some offline review comments that I tried to clarify.

[revans2]

build

[revans2]

I filed #3023 to try and track some possible performance optimizations.