Skip to content

Grammar for plan constraints #20

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.

Sign up for GitHub

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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Grammar for plan constraints #20

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
cac050a
First draft of plan constraints grammar
aaneja Jul 26, 2024
5ea27d8
- Modify grammar to be more precise
aaneja Jul 31, 2024
3fcc611
Fix to latest grammar
aaneja Aug 20, 2024
ff71b40
Add details about how other DB vendors support plan constraints
aaneja Aug 26, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
77 changes: 77 additions & 0 deletions RFC-0007-plan-constraints-grammar.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
# **RFC007 for Presto**

## Grammar for Plan Constraints
Copy link
Contributor

Choose a reason for hiding this comment

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

I would call this feature Plan Hints rather than Plan Constraints. The optimizer may not follow the hints (though we should issue a warning if we don't)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I would call this feature Plan Hints rather than Plan Constraints.

Sure, will rename
Agreed on providing a warning if some/all of the plan hint is not applied


Proposers

* @aaneja
* @ClarenceThreepwood

## Related Issues

* [Overview doc](https://prestodb.io/wp-content/uploads/Search-Space-Improvements-Plan-Constraints.pdf) on Plan Constraints as a tool to control search space
* PrestoDB blog on - [Elevating Presto Query Optimization](https://prestodb.io/blog/2024/03/21/elevating-presto-query-optimization/)

## Summary

This document proposes a grammar for specifying plan constraints

## Background

Plan constraints can be used to lock down critical aspects of an execution plan, such as access method, join method, and join order.


## Proposed Implementation

We propose a grammar for specifying independent plan constraints, which take the form of a SQL comment block that would build an object graph of the constraints. Multiple constraints can be specified in a single place. The grammar is open for extension as we develop more mechanisms to lock down plans.

In this first cut, users can build constraints to control
- Join orders and distributions for INNER JOIN's
- Cardinality (row counts) for base relations and join sub-plans

### Grammar

```
planConstraintString : /*! planConstraint [, ...] */

planConstraint : joinConstraint
| cardinalityConstraint

joinConstraint : joinType (joinNode) [distributionType]

cardinalityConstraint : CARD (joinNode cardinality)

distributionType : [P]
| [R]

joinType : JOIN (defaults to inner join)
| IJ
| LOJ
| ROJ

cardinality : integer constant (positive)

joinNode : (relationName relationName [, ...])

| joinConstraint

| (relationName joinNode)

| (joinNode relationName)

| (joinNode joinNode [, ...])
```


### Examples of constraints

1. Inner Join constraints -
Copy link
Member

Choose a reason for hiding this comment

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

Why can't we just use replicated or paritioned syntax? Imo the brackets and join ((a c [R]) b [P]) might get complicated quickly

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Can you elaborate on what this would look like for the cited example ?

Copy link
Member

Choose a reason for hiding this comment

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

Like dremio or databricks.

Current way also is fine but suggestion is to use explicit names for broadcast/partition etc since the goal of this is to allow users to explictly set the types

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not opposed to this; my only gripe with it is that it that the plan constraint string can get quite verbose, e.g for a 4-table join order - join (d ((a c [REPLICATED]) b [PARTITIONED]) [PARTITIONED] )

Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need this fine grained kind of control. I like the simplicity of just specifying the partitioning of the table, and every other example I found seems to take that approach.

  1. Spark: BROADCAST(T1)
  2. Oracle: PQ_DISTRIBUTE(s BROADCAST, NONE) (which I also find very clunky).
  3. Vertica: you specify inline distrib(L,B)
  4. Dremio: mark BROADCAST inline

You can specify to use syntactic join order if you want to control the join ordering in a more complex way.

I find the existing syntax complex and hard to use.

Copy link
Contributor Author

@aaneja aaneja Sep 17, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

DB2 supports 'join requests' similar to these join hints. It has variants that specify the join method too
Using a join hint allow us to :

  1. Specify partial join order - you don't need to force syntactic join on the rest of the query to force a specific join shape for part of the query tree
  2. Hardcode join orders for tools that generate SQL and cannot guarantee syntactic SQL generation

Copy link
Contributor

Choose a reason for hiding this comment

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

Got it. I see the appeal of specifying a partial join order for auto generated queries, but also would like it to be easy to specify join hints for the common case where people just want to mark some table for broadcast or similar. I wonder if there's an alternative approach we can use to achieve both of these goals

Copy link
Contributor Author

@aaneja aaneja Sep 18, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

We could add Spark style independent hints -

  1. BROADCAST(T1) - Always broadcast T1 in chosen as the build side of a join
  2. BROADCAST(a b) - If the optimizer chooses a logical join of a and b`, and this is a sub-tree of another join graph, use BROADCAST for the join distribution

These will be complementary to the join-order syntax. So the below join hints are equivalent but provide flexibility to the user -

BROADCAST(a b)  join(c (ab))
join (c (a b)[R])

Will think of more examples and incorporate them

1. `join (a (b c))` - Join the relations a,b,c as a right deep tree (denoted by the brackets). Use regular rules for determining join distribution
2. `join (((a c) [R] b) [P])` - In addition to the join order, use a REPLICATED `[R]` join for sub-plan `(a c)` and PARTITIONED `[P]` for `(a c) b`
3. If an inner join condition does not exist between nodes a CrossJoin is automatically inferred
2. Cardinality constraints -
1. `card (c 10)` - Set the output row count estimate of `c` to `10`
Copy link
Contributor

Choose a reason for hiding this comment

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

I would rather not expose this kind of control. Better to specify what you want to have happen with this table, and otherwise leave it be. Seems pretty risky to encode cardinality estimates in the query text.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Can you elaborate on the risk ? I see this card estimate as a simple way to fixup estimation errors for when -

  1. Presto doesn't have stats, but the user is aware of maxcard for a base table
  2. Presto is unable to figure out the right stats because it has a missing stats rule (e.g see the WITH CTE example at L144 below)
  3. Provides a good debugging aid for devs to quickly test what-if scenarios wrt to cardinality estimates

Copy link
Contributor

Choose a reason for hiding this comment

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

The risk I see is that if you are specifying a cardinality of x, you are probably doing it because you want the optimizer to do some particular thing about it. But you don't really know what the optimizer will do with that information, and it could do one thing for a while, and then in a new release there's an optimizer change and it does something else. Because you aren't directly controlling what happens when you specify the cardinality, it's hard to say how it might affect the query, and could be hard to debug if the performance degrades (vs. if you e.g. specify broadcast join and your data gets bigger, it's very clear what happens)

It can also get out of sync with the data (there is always a risk with hand tuning that the optimization will no longer be relevan or will perform worse as the data changes, but specifying a specific cardinality estimate can have more varied and unknown effects).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree that this is a powerful knob to give to the users, one that we can document as such (with caveats)

To aid debugging, we can add CardEstimateBasedSourceInfo similar to how we have a HistoryBasedSourceInfo that will make it clear to the users how the cardinality was arrived at in EXPLAIN/EXPLAIN ANALYZE (and event listener etc.)

Additional safeguards like warnings & metrics can be incorporated too if the stats estimate differ widely from actual runtime observed cardinality

2. `card ((c o) 10)` - When considering a join node of shape `(c o)` set the output row count estimate to `10`

### Other points of note
- Relation names loosely resolve to WITH query aliases (CTE definitions) and table names.A detailed description of the name resolution is out of scope of this RFC (this will be covered in the implementation PR description)