[SPARK-16208][SQL] Add `PropagateEmptyRelation` optimizer #13906

dongjoon-hyun · 2016-06-25T21:07:15Z

What changes were proposed in this pull request?

This PR adds a new logical optimizer, PropagateEmptyRelation, to collapse a logical plans consisting of only empty LocalRelations.

Optimizer Targets

Binary(or Higher)-node Logical Plans
- Union with all empty children.
- Join with one or two empty children (including Intersect/Except).
Unary-node Logical Plans
- Project/Filter/Sample/Join/Limit/Repartition with all empty children.
- Aggregate with all empty children and without AggregateFunction expressions, COUNT.
- Generate with Explode because other UserDefinedGenerators like Hive UDTF returns results.

Sample Query

WITH t1 AS (SELECT a FROM VALUES 1 t(a)),
     t2 AS (SELECT b FROM VALUES 1 t(b) WHERE 1=2)
SELECT a,b
FROM t1, t2
WHERE a=b
GROUP BY a,b
HAVING a>1
ORDER BY a,b

Before

scala> sql("with t1 as (select a from values 1 t(a)), t2 as (select b from values 1 t(b) where 1=2) select a,b from t1, t2 where a=b group by a,b having a>1 order by a,b").explain
== Physical Plan ==
*Sort [a#0 ASC, b#1 ASC], true, 0
+- Exchange rangepartitioning(a#0 ASC, b#1 ASC, 200)
   +- *HashAggregate(keys=[a#0, b#1], functions=[])
      +- Exchange hashpartitioning(a#0, b#1, 200)
         +- *HashAggregate(keys=[a#0, b#1], functions=[])
            +- *BroadcastHashJoin [a#0], [b#1], Inner, BuildRight
               :- *Filter (isnotnull(a#0) && (a#0 > 1))
               :  +- LocalTableScan [a#0]
               +- BroadcastExchange HashedRelationBroadcastMode(List(cast(input[0, int, false] as bigint)))
                  +- *Filter (isnotnull(b#1) && (b#1 > 1))
                     +- LocalTableScan <empty>, [b#1]

After

scala> sql("with t1 as (select a from values 1 t(a)), t2 as (select b from values 1 t(b) where 1=2) select a,b from t1, t2 where a=b group by a,b having a>1 order by a,b").explain
== Physical Plan ==
LocalTableScan <empty>, [a#0, b#1]

How was this patch tested?

Pass the Jenkins tests (including a new testsuite).

SparkQA · 2016-06-25T22:46:15Z

Test build #61242 has finished for PR 13906 at commit 7ddf449.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

rxin · 2016-06-25T22:53:42Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/optimizer/Optimizer.scala

+    case x if x.isInstanceOf[ObjectProducer] || x.isInstanceOf[ObjectConsumer] => x
+
+    // Case 1: If groupingExpressions contains all aggregation expressions, the result is empty.
+    case a @ Aggregate(ge, ae, child) if isEmptyLocalRelation(child) && ae.forall(ge.contains(_)) =>


this kind of blacklisting approach is too risky -- if we were to introduce a new logical node in the future, most likely we will forget to update this rule.

Thank you for review, @rxin .
I see. I will update this PR into whitelist approach.

Ur, at the first, I thought you meant line 1080 for case p: LogicalPlan,

https://github.com/apache/spark/pull/13906/files#diff-a636a87d8843eeccca90140be91d4fafR1080 .

Did I understand your advice correctly?

SparkQA · 2016-06-26T09:07:35Z

Test build #61260 has finished for PR 13906 at commit bd39437.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

dongjoon-hyun · 2016-06-28T05:59:38Z

Hi, @rxin .
I just remembered this PR while looking your whitelist PR. :)
Any advice for this PR?

rxin · 2016-06-28T06:03:39Z

...catalyst/src/test/scala/org/apache/spark/sql/catalyst/optimizer/CollapseEmptyPlanSuite.scala

+import org.apache.spark.sql.catalyst.plans.logical.{LocalRelation, LogicalPlan}
+import org.apache.spark.sql.catalyst.rules.RuleExecutor
+
+class CollapseEmptyPlanSuite extends PlanTest {


you should test something that shouldn't have been converted too

Ur, any other scenario except the existing followings?

test("one non-empty local relation")

test("one non-empty and one empty local relations")

test("aggregating expressions on empty plan")

I'll update to have more.

dongjoon-hyun · 2016-06-28T06:10:23Z

Anyway, thank you for review again, @rxin !

SparkQA · 2016-06-28T08:40:02Z

Test build #61363 has finished for PR 13906 at commit c06ae60.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

rxin · 2016-06-28T20:31:00Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/optimizer/Optimizer.scala

+    // Case 4: The following plans having at least one empty relation return empty results.
+    case p: LogicalPlan if p.children.exists(isEmptyLocalRelation) =>
+      p match {
+        case Join(_, _, Inner, _) | _: Intersect =>


can we move this out rather than doing a two level nesting

rxin · 2016-06-28T20:31:32Z

cc @cloud-fan to take a look too.

rxin · 2016-06-28T20:32:07Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/optimizer/Optimizer.scala

+ *   SELECT SUM(a) FROM t WHERE 1=0 GROUP BY a HAVING COUNT(*)>1 ORDER BY a (Not optimized)
+ * }}}
+ */
+object CollapseEmptyPlan extends Rule[LogicalPlan] with PredicateHelper {


can you actually move this into a separate file? the optimizer is becoming too large and I want to break it apart soon. No point adding new things in this file.

Sure. What name is suitable for this optimizer?

Just CollapseEmptyPlan.scala is okay?

dongjoon-hyun · 2016-06-28T20:51:45Z

Yep. It's done!

SparkQA · 2016-06-28T22:54:10Z

Test build #61409 has finished for PR 13906 at commit bd79a14.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

cloud-fan · 2016-06-29T03:36:40Z

Some more thoughts about it: Currently we only execute Project locally if the underlying relation is LocalRelation. Is it possible that we can also execute Aggregate locally? If it's too hard I'm ok to handle empty relation first.

dongjoon-hyun · 2016-06-29T04:08:42Z

Thank you, @cloud-fan .
It seems to be a good idea to handle operators on LocalRelations.
But, if possible, may I dig that on another PR? :)

cloud-fan · 2016-06-29T04:56:27Z

I'm not sure if this optimization is useful

empty LocalRelation is a corner case and seems not worth to optimize.
the optimization rule in this PR is kind of complex.
if we have better handling for LocalRelation in the futuren(like the LocalNode), this rule will become useless.

cc @marmbrus @yhuai

dongjoon-hyun · 2016-06-29T05:05:01Z

Sounds interesting. You mean LocalNode that computes all local node operators on LocalRelation, right?

dongjoon-hyun · 2016-06-29T05:06:28Z

It sounds promising. Maybe, Spark 2.1?

dongjoon-hyun · 2016-06-29T05:09:49Z

By the way, for complexity, it's 23 line optimizer without blank/comments. In fact, it's less than NullPropagation.

dongjoon-hyun · 2016-06-29T05:35:35Z

For 3, I respect your opinion. I just make another commit for 2. Now, it's 19 lines.

SparkQA · 2016-06-29T07:24:31Z

Test build #61449 has finished for PR 13906 at commit 4d937dc.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

SparkQA · 2016-06-29T12:53:05Z

Test build #61462 has finished for PR 13906 at commit 4bc2452.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

liancheng · 2016-06-30T03:18:39Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/optimizer/CollapseEmptyPlan.scala

+
+    case p: LogicalPlan if p.children.nonEmpty && p.children.forall(isEmptyLocalRelation) =>
+      p match {
+        case _: Project | _: Generate | _: Filter | _: Sample | _: Join |


Actually Generate can't be included here. Our Generate also supports Hive style UDTF, which has a weird semantics: for a UDTF f, after all rows being processed, f.close() will be called, and more rows can be generated within f.close(). This means a UDTF may generate one or more rows even if the underlying input is empty.

See here and PR #5338 for more details.

liancheng · 2016-06-30T03:39:16Z

My feeling is that, this optimization rule is mostly useful for binary plan nodes like inner join and intersection, where we can avoid scanning output of the non-empty side.

On the other hand, for unary plan nodes, firstly it doesn't bring much performance benefits, especially when whole stage codegen is enabled; secondly there are non-obvious and tricky corner cases, like Aggregate and Generate.

That said, although this patch is not a big one, it does introduce non-trivial complexities. For example, I didn't immediately realize that why Aggregate must be special cased at first (COUNT(x) may return 0 for empty input). The Generate case is even trickier.

So my suggestion is to only implement this rule for inner join and intersection, which are much simpler to handle. what do you think?

liancheng · 2016-06-30T03:41:16Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/optimizer/CollapseEmptyPlan.scala

+ */
+object CollapseEmptyPlan extends Rule[LogicalPlan] with PredicateHelper {
+  private def isEmptyLocalRelation(plan: LogicalPlan): Boolean =
+    plan.isInstanceOf[LocalRelation] && plan.asInstanceOf[LocalRelation].data.isEmpty


plan match { case p: LocalRelation => p.data.isEmpty case _ => false }

cloud-fan · 2016-06-30T03:43:24Z

@liancheng , I think we still need to keep some simple rules for unary node, which also helps the binary cases, as the empty relation is propagated up.

liancheng · 2016-06-30T04:07:00Z

@cloud-fan Yea, that's a good point.

dongjoon-hyun · 2016-06-30T10:03:12Z

Thank you so much, @liancheng and @cloud-fan !
I indeed focused on only UnaryNode plans before.
Now I've learned your view points, and reconsider BinaryNode logical plans, mainly Join.

I update the code and PR description according to the comments.

Add more Join optimizations. (@liancheng)
(Intersect is considered in LeftSemi by ReplaceIntersectWithSemiJoin)
Exclude all Generator except Explode. (@liancheng)
Handle SELECT col + 1 … GROUP BY col. (@cloud-fan)
Change isEmptyLocalRelation function to use pattern match. (@liancheng)

SparkQA · 2016-07-01T01:27:06Z

Test build #61581 has finished for PR 13906 at commit 7ab1725.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

dongjoon-hyun · 2016-07-01T04:49:47Z

Oh, please hold on merging this PR. Scala 2.10 reports some errors. I'll inform you again.

dongjoon-hyun · 2016-07-01T05:25:26Z

It's the exact same Scala 2.10 match reachability build error at previous fda51f1 .

The solution is the same. I split the case statements.

SparkQA · 2016-07-01T07:18:20Z

Test build #61598 has finished for PR 13906 at commit 984854b.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

dongjoon-hyun · 2016-07-01T08:20:10Z

Hi, @rxin , @cloud-fan , @liancheng . It's ready for merging again.
Thank you so much for being together with this PR!

cloud-fan · 2016-07-01T14:06:20Z

...catalyst/src/main/scala/org/apache/spark/sql/catalyst/optimizer/PropagateEmptyRelation.scala

+    case p: Union if p.children.forall(isEmptyLocalRelation) =>
+      empty(p)
+
+    case p @ Join(_, _, joinType, _) if p.children.exists(isEmptyLocalRelation) => joinType match {


sorry to be so nit-pick, but it seems better to separate the join case, e.g.

case p @ Join(_, _, Inner, _) if p.children.exists(isEmptyLocalRelation) => empty(p) case p @ Join(_, _, LeftOuter | LeftSemi | LeftAnti, _) if isEmptyLocalRelation(p.left) => empty(p) ...

liancheng · 2016-07-01T14:17:39Z

Merged to master.

@cloud-fan Sorry that I didn't notice your comment while merging it. We may address it in follow-up ones.

dongjoon-hyun · 2016-07-01T15:57:37Z

Thank you for merging, @liancheng , @cloud-fan , and @rxin .

JoshRosen · 2017-05-10T00:55:54Z

I found a bug in the part of this rule which deals with Aggregate; see #17929 for the fix.

…te without grouping ## What changes were proposed in this pull request? The query ``` SELECT 1 FROM (SELECT COUNT(*) WHERE FALSE) t1 ``` should return a single row of output because the subquery is an aggregate without a group-by and thus should return a single row. However, Spark incorrectly returns zero rows. This is caused by SPARK-16208 / apache#13906, a patch which added an optimizer rule to propagate EmptyRelation through operators. The logic for handling aggregates is wrong: it checks whether aggregate expressions are non-empty for deciding whether the output should be empty, whereas it should be checking grouping expressions instead: An aggregate with non-empty grouping expression will return one output row per group. If the input to the grouped aggregate is empty then all groups will be empty and thus the output will be empty. It doesn't matter whether the aggregation output columns include aggregate expressions since that won't affect the number of output rows. If the grouping expressions are empty, however, then the aggregate will always produce a single output row and thus we cannot propagate the EmptyRelation. The current implementation is incorrect and also misses an optimization opportunity by not propagating EmptyRelation in the case where a grouped aggregate has aggregate expressions (in other words, `SELECT COUNT(*) from emptyRelation GROUP BY x` would _not_ be optimized to `EmptyRelation` in the old code, even though it safely could be). This patch resolves this issue by modifying `PropagateEmptyRelation` to consider only the presence/absence of grouping expressions, not the aggregate functions themselves, when deciding whether to propagate EmptyRelation. ## How was this patch tested? - Added end-to-end regression tests in `SQLQueryTest`'s `group-by.sql` file. - Updated unit tests in `PropagateEmptyRelationSuite`. Author: Josh Rosen <joshrosen@databricks.com> Closes apache#17929 from JoshRosen/fix-PropagateEmptyRelation.

…te without grouping ## What changes were proposed in this pull request? The query ``` SELECT 1 FROM (SELECT COUNT(*) WHERE FALSE) t1 ``` should return a single row of output because the subquery is an aggregate without a group-by and thus should return a single row. However, Spark incorrectly returns zero rows. This is caused by SPARK-16208 / #13906, a patch which added an optimizer rule to propagate EmptyRelation through operators. The logic for handling aggregates is wrong: it checks whether aggregate expressions are non-empty for deciding whether the output should be empty, whereas it should be checking grouping expressions instead: An aggregate with non-empty grouping expression will return one output row per group. If the input to the grouped aggregate is empty then all groups will be empty and thus the output will be empty. It doesn't matter whether the aggregation output columns include aggregate expressions since that won't affect the number of output rows. If the grouping expressions are empty, however, then the aggregate will always produce a single output row and thus we cannot propagate the EmptyRelation. The current implementation is incorrect and also misses an optimization opportunity by not propagating EmptyRelation in the case where a grouped aggregate has aggregate expressions (in other words, `SELECT COUNT(*) from emptyRelation GROUP BY x` would _not_ be optimized to `EmptyRelation` in the old code, even though it safely could be). This patch resolves this issue by modifying `PropagateEmptyRelation` to consider only the presence/absence of grouping expressions, not the aggregate functions themselves, when deciding whether to propagate EmptyRelation. ## How was this patch tested? - Added end-to-end regression tests in `SQLQueryTest`'s `group-by.sql` file. - Updated unit tests in `PropagateEmptyRelationSuite`. Author: Josh Rosen <joshrosen@databricks.com> Closes #17929 from JoshRosen/fix-PropagateEmptyRelation. (cherry picked from commit a90c5cd) Signed-off-by: Wenchen Fan <wenchen@databricks.com>

…te without grouping The query ``` SELECT 1 FROM (SELECT COUNT(*) WHERE FALSE) t1 ``` should return a single row of output because the subquery is an aggregate without a group-by and thus should return a single row. However, Spark incorrectly returns zero rows. This is caused by SPARK-16208 / #13906, a patch which added an optimizer rule to propagate EmptyRelation through operators. The logic for handling aggregates is wrong: it checks whether aggregate expressions are non-empty for deciding whether the output should be empty, whereas it should be checking grouping expressions instead: An aggregate with non-empty grouping expression will return one output row per group. If the input to the grouped aggregate is empty then all groups will be empty and thus the output will be empty. It doesn't matter whether the aggregation output columns include aggregate expressions since that won't affect the number of output rows. If the grouping expressions are empty, however, then the aggregate will always produce a single output row and thus we cannot propagate the EmptyRelation. The current implementation is incorrect and also misses an optimization opportunity by not propagating EmptyRelation in the case where a grouped aggregate has aggregate expressions (in other words, `SELECT COUNT(*) from emptyRelation GROUP BY x` would _not_ be optimized to `EmptyRelation` in the old code, even though it safely could be). This patch resolves this issue by modifying `PropagateEmptyRelation` to consider only the presence/absence of grouping expressions, not the aggregate functions themselves, when deciding whether to propagate EmptyRelation. - Added end-to-end regression tests in `SQLQueryTest`'s `group-by.sql` file. - Updated unit tests in `PropagateEmptyRelationSuite`. Author: Josh Rosen <joshrosen@databricks.com> Closes #17929 from JoshRosen/fix-PropagateEmptyRelation. (cherry picked from commit a90c5cd) Signed-off-by: Wenchen Fan <wenchen@databricks.com>

…te without grouping ## What changes were proposed in this pull request? The query ``` SELECT 1 FROM (SELECT COUNT(*) WHERE FALSE) t1 ``` should return a single row of output because the subquery is an aggregate without a group-by and thus should return a single row. However, Spark incorrectly returns zero rows. This is caused by SPARK-16208 / apache#13906, a patch which added an optimizer rule to propagate EmptyRelation through operators. The logic for handling aggregates is wrong: it checks whether aggregate expressions are non-empty for deciding whether the output should be empty, whereas it should be checking grouping expressions instead: An aggregate with non-empty grouping expression will return one output row per group. If the input to the grouped aggregate is empty then all groups will be empty and thus the output will be empty. It doesn't matter whether the aggregation output columns include aggregate expressions since that won't affect the number of output rows. If the grouping expressions are empty, however, then the aggregate will always produce a single output row and thus we cannot propagate the EmptyRelation. The current implementation is incorrect and also misses an optimization opportunity by not propagating EmptyRelation in the case where a grouped aggregate has aggregate expressions (in other words, `SELECT COUNT(*) from emptyRelation GROUP BY x` would _not_ be optimized to `EmptyRelation` in the old code, even though it safely could be). This patch resolves this issue by modifying `PropagateEmptyRelation` to consider only the presence/absence of grouping expressions, not the aggregate functions themselves, when deciding whether to propagate EmptyRelation. ## How was this patch tested? - Added end-to-end regression tests in `SQLQueryTest`'s `group-by.sql` file. - Updated unit tests in `PropagateEmptyRelationSuite`. Author: Josh Rosen <joshrosen@databricks.com> Closes apache#17929 from JoshRosen/fix-PropagateEmptyRelation.

…te without grouping The query ``` SELECT 1 FROM (SELECT COUNT(*) WHERE FALSE) t1 ``` should return a single row of output because the subquery is an aggregate without a group-by and thus should return a single row. However, Spark incorrectly returns zero rows. This is caused by SPARK-16208 / apache#13906, a patch which added an optimizer rule to propagate EmptyRelation through operators. The logic for handling aggregates is wrong: it checks whether aggregate expressions are non-empty for deciding whether the output should be empty, whereas it should be checking grouping expressions instead: An aggregate with non-empty grouping expression will return one output row per group. If the input to the grouped aggregate is empty then all groups will be empty and thus the output will be empty. It doesn't matter whether the aggregation output columns include aggregate expressions since that won't affect the number of output rows. If the grouping expressions are empty, however, then the aggregate will always produce a single output row and thus we cannot propagate the EmptyRelation. The current implementation is incorrect and also misses an optimization opportunity by not propagating EmptyRelation in the case where a grouped aggregate has aggregate expressions (in other words, `SELECT COUNT(*) from emptyRelation GROUP BY x` would _not_ be optimized to `EmptyRelation` in the old code, even though it safely could be). This patch resolves this issue by modifying `PropagateEmptyRelation` to consider only the presence/absence of grouping expressions, not the aggregate functions themselves, when deciding whether to propagate EmptyRelation. - Added end-to-end regression tests in `SQLQueryTest`'s `group-by.sql` file. - Updated unit tests in `PropagateEmptyRelationSuite`. Author: Josh Rosen <joshrosen@databricks.com> Closes apache#17929 from JoshRosen/fix-PropagateEmptyRelation. (cherry picked from commit a90c5cd) Signed-off-by: Wenchen Fan <wenchen@databricks.com>

rxin reviewed Jun 25, 2016
View reviewed changes

rxin reviewed Jun 28, 2016
View reviewed changes

liancheng reviewed Jun 30, 2016
View reviewed changes

dongjoon-hyun added 10 commits June 30, 2016 21:39

[SPARK-16208][SQL] Add CollapseEmptyPlan optimizer

af580b7

According to the comments, use whitelisting approach.

78e0064

Add inner join and intersection cases and more testcases.

43d916c

Make CollapseEmptyPlan.scala.

f0aa4db

Remove Distinct/Intersect/Except according to BasicOperators strategy.

e3e88be

Make it clearer.

adc7507

Improve Joins according to the comments.

3350b66

Use AggregateFunction instead of DeclarativeAggregate and add comments.

0b7a9b1

Rename CollapseEmptyPlan to PropagateEmptyRelation.

ef1de75

Clean up testcases.

2892372

Fix Scala 2.10 match reachability build error

984854b

cloud-fan reviewed Jul 1, 2016
View reviewed changes

asfgit closed this in c553976 Jul 1, 2016

dongjoon-hyun deleted the SPARK-16208 branch July 20, 2016 07:41

JoshRosen mentioned this pull request May 10, 2017

[SPARK-20686][SQL] PropagateEmptyRelation incorrectly handles aggregate without grouping #17929

Closed

[SPARK-16208][SQL] Add PropagateEmptyRelation optimizer #13906

[SPARK-16208][SQL] Add PropagateEmptyRelation optimizer #13906

Conversation

dongjoon-hyun commented Jun 25, 2016 • edited

What changes were proposed in this pull request?

How was this patch tested?

SparkQA commented Jun 25, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SparkQA commented Jun 26, 2016

dongjoon-hyun commented Jun 28, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dongjoon-hyun commented Jun 28, 2016

SparkQA commented Jun 28, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rxin commented Jun 28, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dongjoon-hyun commented Jun 28, 2016

SparkQA commented Jun 28, 2016

cloud-fan commented Jun 29, 2016

dongjoon-hyun commented Jun 29, 2016

cloud-fan commented Jun 29, 2016

dongjoon-hyun commented Jun 29, 2016

dongjoon-hyun commented Jun 29, 2016

dongjoon-hyun commented Jun 29, 2016

dongjoon-hyun commented Jun 29, 2016 • edited

SparkQA commented Jun 29, 2016

SparkQA commented Jun 29, 2016

liancheng Jun 30, 2016 • edited

Choose a reason for hiding this comment

liancheng commented Jun 30, 2016

Choose a reason for hiding this comment

cloud-fan commented Jun 30, 2016

liancheng commented Jun 30, 2016

dongjoon-hyun commented Jun 30, 2016

SparkQA commented Jul 1, 2016

dongjoon-hyun commented Jul 1, 2016

dongjoon-hyun commented Jul 1, 2016

SparkQA commented Jul 1, 2016

dongjoon-hyun commented Jul 1, 2016

Choose a reason for hiding this comment

liancheng commented Jul 1, 2016

dongjoon-hyun commented Jul 1, 2016

JoshRosen commented May 10, 2017

[SPARK-16208][SQL] Add `PropagateEmptyRelation` optimizer #13906

[SPARK-16208][SQL] Add `PropagateEmptyRelation` optimizer #13906

dongjoon-hyun commented Jun 25, 2016 •

edited

dongjoon-hyun commented Jun 29, 2016 •

edited

liancheng Jun 30, 2016 •

edited