Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Welcome to the PR tracker for NoisePage! We're excited that you're interested in improving our system.
Before continuing with opening a PR, please read through the Pull Request Process page on our wiki. PRs that do not follow our guidelines will be immediately closed. In general, you should avoid creating a PR until you are reasonably confident the tests should pass, having tested locally first.
Please choose the appropriate labels on the Github panel and feel free to assign yourself. Additionally, if your PR solves an open issue, please link the issue on the Github panel. However, please DO NOT assign any reviewers to your PR. We will decide who best to assign for a review.
Heading
Please choose an appropriate heading for your PR, relevant to the changes you have made. For example, if your PR addresses the
LIMIT
clause onIndexScan
s, an appropriate PR name would beIndex Scan Limit
.Description
Please create a description of the issue your PR solves, and how you went about implementing your solution. An example from a PR by @thepinetree follows:
Limit clauses are currently not propagated to the
IndexScanPlanNode
in the optimizer and as a result, the execution engine can't take advantage of the limit during operation. Instead, this is done in-post, with aLimitPlanNode
doing so after the index scan is completed.This PR adds functionality for the limit value to be pushed down to an index scan, and is used in TPC-C. Limits values will be pushed down to their child
LogicalGet
via transformation rule and converted to values in thePhysicalIndexScan
which are then set in theIndexScanPlanNode
. To appropriately act on theLimit
value, we also add infrastructure for optional properties for a child to satisfy, which is tracked only in anOptimizer
node. The PR also moves theOrderByOrderingType
from the optimizer to the catalog as a precursor to further changes to involve the sort direction of columns in creating/scanning an index.Remaining Tasks
Again, you should only create PR once you are reasonably confident you are near completion. However, if there are some tasks still remaining before the PR is ready to merge, please create a checklist to track active progress. An example from a PR by @thepinetree follows:
📌 TODOs:
Stash limit in OptimizerContext for pushdown (INVALID)Performance
If your PR has the potential to greatly affect the performance of the system, please address these by benchmarking your changes with respect to master, or profiling the performance. You may do this in one of the following ways:
Inline a table outlining performance results. An example from a PR @gonzalezjo follows:
Create a Google Sheets document noting baseline performance and scalability, as is done here in an example from @mbutrovich
Create an SVG of profiling results per the EC2 profiling instructions, as is done here in an example from @thepinetree
Further Work
If your PR unlocked the potential for further improvement, please note them here and create additional issues! Do the same if you discovered bugs in the process of development. An example from a PR by @gonzalezjo follows:
Investigating loopback and TCP overhead
This is probably a dead end, but less of a dead end than libevent/epoll stuff.
I'd like to work on improving our INET socket overhead, but at this point, that might not be doable without being a kernel engineer. Nothing I tried measurably reduced loopback and/or INET overhead, and I tried a lot. Still, I think it's worth digging some more.
One question I have is how much of the speedup comes from avoiding TCP, and how much comes from using a glorified pipe instead of loopback. This would be interesting to know, but I have no idea how I'd measure, and I'm not convinced that I'd be able to make anything useful from the answer.
Here's an empty template to format yourself!
Heading
Description
Remaining tasks
Performance
Further work