Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

colexec: fix performance inefficiency in materializer #48669

Merged
merged 2 commits into from
May 12, 2020

Conversation

yuzefovich
Copy link
Member

@yuzefovich yuzefovich commented May 11, 2020

colexec: fix performance inefficiency in materializer

We mistakenly were passing sqlbase.DatumAlloc by value, and not by
pointer, and as a result we would always be allocating 16 datums but
using only 1 - i.e. we were not only not pooling the allocations, but
actually making a bunch of useless allocations as well.

This inefficiency becomes noticeable when the vectorized query returns
many rows and when we have wrapped processors and those processors get
a lot of input rows - in all cases when we need to materialize a lot.
For example, TPC-H query 16 sees about 10% improvement (it returns 18k
rows) and TPC-DS query 6 sees 2x improvement (it has wrapped hash
aggregator with a decimal column) with this fix.

Release note (performance improvement): A performance inefficiency has
been fixed in the vectorized execution engine which results in speed ups
on all queries when run via the vectorized engine, with most noticeable
gains on the queries that output many rows.

sqlbase: prohibit copying DatumAlloc by value

This commit adds _ util.NoCopy to DatumAlloc struct to prevent us
from misusing it. A few places failed the linter, and those have been
addressed, but there was no performance problems AFAICT due to the
removed copies by value.

Release note: None

We mistakenly were passing `sqlbase.DatumAlloc` by value, and not by
pointer, and as a result we would always be allocating 16 datums but
using only 1 - i.e. we were not only not pooling the allocations, but
actually making a bunch of useless allocations as well.

This inefficiency becomes noticeable when the vectorized query returns
many rows and when we have wrapped processors and those processors get
a lot of input rows - in all cases when we need to materialize a lot.
For example, TPC-H query 16 sees about 10% improvement (it returns 18k
rows) and TPC-DS query 6 sees 2x improvement (it has wrapped hash
aggregator with a decimal column) with this fix.

Release note (performance improvement): A performance inefficiency has
been fixed in the vectorized execution engine which results in speed ups
on all queries when run via the vectorized engine, with most noticeable
gains on the queries that output many rows.
@yuzefovich yuzefovich requested review from asubiotto and a team May 11, 2020 00:17
@cockroach-teamcity
Copy link
Member

This change is Reviewable

@yuzefovich
Copy link
Member Author

For some context, I noticed this on tpcdsvec run:

09:05:28 test.go:190: test status: [q6] took about 57.07s to run on both configs
09:05:28 test.go:190: test status: WARNING: suboptimal plan when stats are present
no stats: 22.05s	with stats: 57.07s

so I looked into query 6, and it would run in like 15 seconds with vectorize=off but in 28 seconds with vectorize=on.

Here is what showed up in the profile
Screen Shot 2020-05-10 at 5 19 05 PM
and with this fix it runs in about 15 seconds as well with vectorize=on.

@jordanlewis
Copy link
Member

LGTM! Nice find! (I guess there are some problems w/ nocopy, but this is great)

@yuzefovich
Copy link
Member Author

Yeah, my second commit was WIP - I was lazy to run the linter myself, and now I updated the second commit to appease the linter (nothing bad was shaken out, but I think it is beneficial to have util.NoCopy in DatumAlloc). Also, I think we should backport the first commit to 20.1 and 19.2.

RFAL.

@blathers-crl
Copy link

blathers-crl bot commented May 11, 2020

❌ The GitHub CI (Cockroach) build has failed on 6a3dc88d.

🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is otan.

This commit adds `_ util.NoCopy` to `DatumAlloc` struct to prevent us
from misusing it. A few places failed the linter, and those have been
addressed, but there was no performance problems AFAICT due to the
removed copies by value.

Release note: None
Copy link
Contributor

@asubiotto asubiotto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

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

@yuzefovich
Copy link
Member Author

TFTR!

bors r+

@craig
Copy link
Contributor

craig bot commented May 12, 2020

Merge conflict (retrying...)

@craig
Copy link
Contributor

craig bot commented May 12, 2020

Build failed (retrying...)

@craig
Copy link
Contributor

craig bot commented May 12, 2020

Build succeeded

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants