Implement `DISTINCT ON` from Postgres #7981

gruuya · 2023-10-30T10:40:56Z

Which issue does this PR close?

Closes #7827.
Closes #8008.

Rationale for this change

While in principle the output of DISTINCT ON can be emulated by combining several aggregation, projection and sorting queries/operators, in practice this is very verbose and impractical for users, unlike DISTINCT ON which is quite succinct. On the other hand that does mean that DISTINCT ON can be optimized into the equivalent representation under the hood during logical planning, while at the same time providing the compact syntactical interface.

What changes are included in this PR?

A new logical plan sub-variety for handling the DISTINCT ON from Postgres.
Parsing and planning for it
Optimization which converts it into the equivalent representation using the more common logical plan primitives
Proto serialization
Tests

Are these changes tested?

Yes, there are also new SLTs.

Are there any user-facing changes?

SQL support extends to encompass DISTINCT ON queries.

…expressions

gruuya · 2023-10-31T11:53:06Z

datafusion/sqllogictest/test_files/distinct_on.slt

All tests here were compared for accuracy against Postgres.

Note that, while the docs state that in the absence of the ORDER BY clause the output is unpredictable, in practice I've noticed it is stable on Postgres for the table below, whereas that isn't the case for DataFusion, hence why I omitted those tests for now.

Any ideas on what else can be tested here are welcome (cc @universalmind303).

gruuya · 2023-10-31T11:56:38Z

datafusion/optimizer/src/common_subexpr_eliminate.rs

        if affected_id.is_empty() {
+            // Alias aggregation epxressions if they have changed
+            // TODO: This should have really been identified above and handled in the `else` branch
+            let aggr_exprs = new_aggr_expr
+                .iter()
+                .zip(aggr_expr.iter())
+                .map(|(new_expr, old_expr)| {
+                    new_expr.clone().alias_if_changed(old_expr.display_name()?)
+                })
+                .collect::<Result<Vec<Expr>>>()?;
            // Since group_epxr changes, schema changes also. Use try_new method.
-            Aggregate::try_new(Arc::new(new_input), new_group_expr, new_aggr_expr)
+            Aggregate::try_new(Arc::new(new_input), new_group_expr, aggr_exprs)
                .map(LogicalPlan::Aggregate)


I don't yet understand why this wasn't identified/aliased automatically, but I found this part to be necessary in order to get DISTINCT ON with complex expressions to work.

Ok, I think I understand what is going on:

in general the root aggregation expressions need not be rewritten/aliased above since they can only appear once (i.e. they're not common), so this is ok

however, some of their child expressions may get rewritten; an example is the query select distinct on (c1 + 1) c2 from test order by c1 + 1, c3, where the initial aggregation of the sole projected field gets rewritten from FIRST_VALUE(test.column2) ORDER BY [test.column1 + Int64(1) ASC NULLS LAST, test.column3 ASC NULLS LAST] to FIRST_VALUE(test.column2) ORDER BY [test.column1 + Int64(1)Int64(1)test.column1 AS test.column1 + Int64(1) ASC NULLS LAST, test.column3 ASC NULLS LAST] (i.e. c1 + 1 is a common expression of it and the ON expression so it gets rewritten)

consequently the new schema will be different from the original one

I think this explains the behavior I've encountered here, and that this behavior is not anomalous. The only question is whether there is a better way to align the new aggregation schema with the old one besides aliasing as above.

Maybe @waynexia has some thoughts

Btw, I've now clarified this comment since it was misleading, i.e. the aliasing should really be done in build_recover_project_plan once qualified aliasing is enabled.

gruuya · 2023-10-31T12:03:00Z

datafusion/expr/src/logical_plan/plan.rs

+    ) -> Result<Self> {
+        let on_expr = normalize_cols(on_expr, input.as_ref())?;
+
+        // Create fields with any qualifier stuffed in the name itself


This is sort of a hack, but the reason I was forced to do it is so that the plan schema remains unchanged after replace_distinct_aggregate. In particular, in that optimizer I alias the final projected expressions with the selection expression display name, but that always results in a schema without qualifiers (with any original qualifier crammed into the field name).

I feel like this case should be handled by Projection::try_new_with_schema over at replace_distinct_aggregate, but it seems that after #7919 the custom schema doesn't propagate through the optimization chain.

UPDATE: I've opened a related issue for this: #8008

This is sort of a hack, but the reason I was forced to do it is so that the plan schema remains unchanged after replace_distinct_aggregate.

Note #7997 may be related

alamb · 2023-11-01T18:47:08Z

I am sorry -- I have seen this PR but I am somewhat backed up on reviews

waynexia · 2023-11-02T03:34:51Z

datafusion/expr/src/logical_plan/plan.rs

+            LogicalPlan::Distinct(Distinct::All(input)) => input.schema(),
+            LogicalPlan::Distinct(Distinct::On(DistinctOn { schema, .. })) => schema,


Add api-change label for this diff

waynexia · 2023-11-02T03:44:41Z

datafusion/sqllogictest/test_files/distinct_on.slt

These cases are excellent 👍 . It might be better if we could include some negative cases. Here are two I got from PG:

SELECT DISTINCT ON () c1, c2 FROM aggregate_test_100 ORDER BY c1, c3; ERROR: syntax error at or near ")" LINE 1: SELECT DISTINCT ON () c1, c2 FROM aggregate_test_100 ORDER B... SELECT DISTINCT ON (c2) c1, c2 FROM aggregate_test_100 ORDER BY c1, c3; ERROR: SELECT DISTINCT ON expressions must match initial ORDER BY expressions LINE 1: SELECT DISTINCT ON (c2) c1, c2 FROM aggregate_test_100 ORDER...

Thanks! Also good catch, the first example was throwing a panic; added handling and a test case for it.

…_distinct_aggregate optimizer

alamb

Thanks @gruuya -- this is looking pretty close.

datafusion/optimizer/src/replace_distinct_aggregate.rs

alamb · 2023-11-02T19:55:44Z

datafusion/expr/src/logical_plan/plan.rs

+    pub on_expr: Vec<Expr>,
+    /// The selected projection expression list
+    pub select_expr: Vec<Expr>,
+    /// The `ORDER BY` clause, whose initial expressions must match those of the `ON` clause


Since the same list of exprs is included in both the select_list and sort_exprs I wonder if it would be less error prone to have references rather than keep three parallel lists:

/// The selected projection expression list pub select_expr: Vec<Expr>, /// The sort expressions pub sort_expr: Vec<Expr>, /// the number of prefix columns from `sort_expr` that form the `ON` clause used for deduplicating

Yeah, on_expr and sort_expr should have a (partial) overlap (select_expr and sort_expr are arbitrary and different in general).

Condensing on_expr and sort_expr into one is doable, though it seems to me it would introduce more complexity, and make the logic harder to grasp. For starters sort_expr is not an exact super-set of on_expr, but instead wraps them inside Expr::Sorts to capture asc and nulls_first, but it can also be omitted (unlike ON exprs). On the other hand, these two are parsed at different places: first the on_expr is parsed in select_to_plan, and then sort_expr is extracted in order_by.

So in order to keep them both in one vec we'd have to: a) add an additional field to DistinctOn to track the length of the ON expressions as you mention (e.g. on_expr_count), b) if there are no actual sort_expr provided keep the ON expressions in them, otherwise validate that the wrapped sorting expressions match the existing ON expressions and replace the vector with the sorting expressions, and then c) inside replace_distinct_aggregate deconstruct that. That would mean take on_expr_count first expressions from sort_expr, and unwrapping the underlying expressions from Expr::Sort in case sort expression length is > on_expr_count. In case sort expression length is equal to on_expr_count it could mean no ORDER BY was provided (no need for unwrapping), or the ORDER BY expressions match the ON expressions modulo the aforementioned sorting specifiers (asc and nulls_first).

This strikes me as less clear all in all, though if you'd prefer it I'll make that change.

I think your explanation makes sense. Maybe we can take some of this rationale (e.g. that sort_exprs are not a superset as they are wrapped by Expr::Sort) and put them into the doc comments. We can do this as a follow on PR

alamb · 2023-11-02T19:56:32Z

datafusion/optimizer/src/common_subexpr_eliminate.rs

        if affected_id.is_empty() {
+            // Alias aggregation epxressions if they have changed
+            // TODO: This should have really been identified above and handled in the `else` branch
+            let aggr_exprs = new_aggr_expr
+                .iter()
+                .zip(aggr_expr.iter())
+                .map(|(new_expr, old_expr)| {
+                    new_expr.clone().alias_if_changed(old_expr.display_name()?)
+                })
+                .collect::<Result<Vec<Expr>>>()?;
            // Since group_epxr changes, schema changes also. Use try_new method.
-            Aggregate::try_new(Arc::new(new_input), new_group_expr, new_aggr_expr)
+            Aggregate::try_new(Arc::new(new_input), new_group_expr, aggr_exprs)
                .map(LogicalPlan::Aggregate)


Maybe @waynexia has some thoughts

alamb · 2023-11-02T19:56:52Z

datafusion/optimizer/src/common_subexpr_eliminate.rs

-        Projection::try_new(col_exprs, Arc::new(input))
-            .expect("Cannot build projection plan from an invalid schema"),
-    )
+    Ok(LogicalPlan::Projection(Projection::try_new(


alamb · 2023-11-02T19:57:10Z

datafusion/optimizer/src/replace_distinct_aggregate.rs

@@ -32,6 +36,22 @@ use datafusion_expr::{Aggregate, Distinct, LogicalPlan};
 /// ```text
 /// SELECT a, b FROM tab GROUP BY a, b
 /// ```
+///
+/// On the other hand, for a `DISTINCT ON` query the replacement is


Thank you -- this is very helpful to understand what is going on

alamb · 2023-11-02T19:59:51Z

datafusion/sqllogictest/test_files/distinct_on.slt

+# order by the third
+# TODO: Note that the value for 'a' is actually degenerate, and while Postgres
+# returns the actual first match (4), DataFusion returns the last one, presumably
+# because `first_value` aggregation function doesn't have a dedicated `GroupsAccumulator`


this doesn't make sense to me -- we should get the correct values, regardless of the presence of a groups accumulator

Will investigate in more depth and report back. (It's indicative that the equivalent query without using DISTINCT ON returns the same results.)

Oh I see what this is, it's another case of unstable sort, i.e. the sorted rows that have equal ordering expressions evaluations do not preserve the original order of those rows (but they're stable in the sense that output is always the same):

❯ select c1, c2, c3 from test order by c1, c3; +----+----+------+ | c1 | c2 | c3 | +----+----+------+ | a | 5 | -101 | | a | 4 | -101 | | a | 1 | -85 | | a | 3 | -72 | | a | 1 | -56 | ...

I've removed the misleading comment now.

alamb · 2023-11-02T20:00:25Z

I am a little worried about the TODO and the seemingly incorrect results,

alamb

Thank you @gruuya -- I think this PR is looking very nice. My only hesitation I have is the schema rewriting code. My concern is that changing the schema in the LogicalPlan nodes when the node doesn't logically change the schema seems like be breaks an invariant and thus will be brittle (aka this feature may break with combined with other complex queries).

I read #8008 and I think we should figure out what is going on there before merging this

I actually tried merging this branch up from master to get the fix for #7997 and removing the workaround, and sadly it still errored

alamb · 2023-11-04T11:00:04Z

datafusion/expr/src/logical_plan/plan.rs

+    pub on_expr: Vec<Expr>,
+    /// The selected projection expression list
+    pub select_expr: Vec<Expr>,
+    /// The `ORDER BY` clause, whose initial expressions must match those of the `ON` clause


I think your explanation makes sense. Maybe we can take some of this rationale (e.g. that sort_exprs are not a superset as they are wrapped by Expr::Sort) and put them into the doc comments. We can do this as a follow on PR

datafusion/optimizer/src/replace_distinct_aggregate.rs

alamb · 2023-11-04T11:14:01Z

datafusion/sqllogictest/test_files/distinct_on.slt

+
+# Basic example + omit ON column from selection
+query I
+SELECT DISTINCT ON (c1) c2 FROM aggregate_test_100 ORDER BY c1, c3;


Can you maybe also include an explain plan here so we can validate the plan?

Something like

EXPLAIN SELECT DISTINCT ON (c1) c3, c2 FROM aggregate_test_100 ORDER BY c1, c3;

Good idea, adding that test as well!

alamb · 2023-11-04T11:16:51Z

datafusion/optimizer/src/replace_distinct_aggregate.rs

+                    // this on it's own isn't enough to guarantee the proper output order of the grouping
+                    // (`ON`) expression, so we need to sort those as well.
+                    LogicalPlanBuilder::from(plan)
+                        .sort(sort_expr[..on_expr.len()].to_vec())?


Would it make sense to sort the input prior to aggregating it? It seems like sorting to do the aggregate and then sorting again is not as efficient as being able to just sort once and reuse the output.

In theory the optimizer should handle this rewrite, but it might be better to just start with the sort under the aggregate

Yeah, my thinking was that the first_value aggregation actually doesn't do any real sorting and is more like top-1, i.e. it only works on the incoming stream and picks up one row per-grouping set (ON clause), updating it if it's a better match according to the sorting expressions:
https://github.com/apache/arrow-datafusion/blob/2af326a0bdbb60e7d7420089c7aa9ff22c7319ee/datafusion/physical-expr/src/aggregate/first_last.rs#L236-L244
The subsequent actual sort works on the grouped data, so it should have a much lower cardinality.

Whereas if we sorted prior to aggregation then, I think we would materialize all the data initially (whether in memory or by spilling) only to throw away most of it, but I could be wrong.

Granted I haven't done any perf testing between the two approaches for now, this is just from my reading of the code.

I see now that my assumptions were wrong, and that indeed sorting gets pulled down beneath aggregation during physical planning anyway. I do think that in the case of FIRST_VALUE with ORDER BY this is sub-optimal, since that problem reduces to a partitioned top-1 problem, which doesn't need to work on pre-sorted input I think.

Either way, even when I pull sorting beneath the aggregation, I still find I end up needing another post-aggregation sort to get the correct order for the ON clause expressions, since presumably AggregateExec doesn't preserve order:

❯ explain select distinct on (c1) c1, c2 from test order by c1, c3; +---------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | plan_type | plan | +---------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | logical_plan | Projection: FIRST_VALUE(test.c1) ORDER BY [test.c1 ASC NULLS LAST, test.c3 ASC NULLS LAST] AS test.c1, FIRST_VALUE(test.c2) ORDER BY [test.c1 ASC NULLS LAST, test.c3 ASC NULLS LAST] AS test.c2 | | | Aggregate: groupBy=[[test.c1]], aggr=[[FIRST_VALUE(test.c1) ORDER BY [test.c1 ASC NULLS LAST, test.c3 ASC NULLS LAST], FIRST_VALUE(test.c2) ORDER BY [test.c1 ASC NULLS LAST, test.c3 ASC NULLS LAST]]] | | | Sort: test.c1 ASC NULLS LAST, test.c3 ASC NULLS LAST | | | TableScan: test projection=[c1, c2, c3] | | physical_plan | ProjectionExec: expr=[FIRST_VALUE(test.c1) ORDER BY [test.c1 ASC NULLS LAST, test.c3 ASC NULLS LAST]@1 as test.c1, FIRST_VALUE(test.c2) ORDER BY [test.c1 ASC NULLS LAST, test.c3 ASC NULLS LAST]@2 as test.c2] | | | AggregateExec: mode=FinalPartitioned, gby=[c1@0 as c1], aggr=[FIRST_VALUE(test.c1), FIRST_VALUE(test.c2)], ordering_mode=Sorted | | | SortExec: expr=[c1@0 ASC NULLS LAST] | | | CoalesceBatchesExec: target_batch_size=8192 | | | RepartitionExec: partitioning=Hash([c1@0], 10), input_partitions=10 | | | AggregateExec: mode=Partial, gby=[c1@0 as c1], aggr=[FIRST_VALUE(test.c1), FIRST_VALUE(test.c2)], ordering_mode=Sorted | | | RepartitionExec: partitioning=RoundRobinBatch(10), input_partitions=1 | | | SortExec: expr=[c1@0 ASC NULLS LAST,c3@2 ASC NULLS LAST] | | | CsvExec: file_groups={1 group: [[Users/markogrujic/Splitgraph/arrow-datafusion/testing/data/csv/aggregate_test_100.csv]]}, projection=[c1, c2, c3], has_header=true | | | | +---------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

compare that with the currently generated plans which do get the order correct:

❯ explain select distinct on (c1) c1, c2 from test order by c1, c3; +---------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | plan_type | plan | +---------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | logical_plan | Projection: FIRST_VALUE(test.c1) ORDER BY [test.c1 ASC NULLS LAST, test.c3 ASC NULLS LAST] AS test.c1, FIRST_VALUE(test.c2) ORDER BY [test.c1 ASC NULLS LAST, test.c3 ASC NULLS LAST] AS test.c2 | | | Sort: test.c1 ASC NULLS LAST | | | Aggregate: groupBy=[[test.c1]], aggr=[[FIRST_VALUE(test.c1) ORDER BY [test.c1 ASC NULLS LAST, test.c3 ASC NULLS LAST], FIRST_VALUE(test.c2) ORDER BY [test.c1 ASC NULLS LAST, test.c3 ASC NULLS LAST]]] | | | TableScan: test projection=[c1, c2, c3] | | physical_plan | ProjectionExec: expr=[FIRST_VALUE(test.c1) ORDER BY [test.c1 ASC NULLS LAST, test.c3 ASC NULLS LAST]@1 as test.c1, FIRST_VALUE(test.c2) ORDER BY [test.c1 ASC NULLS LAST, test.c3 ASC NULLS LAST]@2 as test.c2] | | | SortPreservingMergeExec: [c1@0 ASC NULLS LAST] | | | SortExec: expr=[c1@0 ASC NULLS LAST] | | | AggregateExec: mode=FinalPartitioned, gby=[c1@0 as c1], aggr=[FIRST_VALUE(test.c1), FIRST_VALUE(test.c2)] | | | CoalesceBatchesExec: target_batch_size=8192 | | | RepartitionExec: partitioning=Hash([c1@0], 10), input_partitions=10 | | | AggregateExec: mode=Partial, gby=[c1@0 as c1], aggr=[FIRST_VALUE(test.c1), FIRST_VALUE(test.c2)], ordering_mode=Sorted | | | SortExec: expr=[c1@0 ASC NULLS LAST,c3@2 ASC NULLS LAST] | | | RepartitionExec: partitioning=RoundRobinBatch(10), input_partitions=1 | | | CsvExec: file_groups={1 group: [[Users/markogrujic/Splitgraph/arrow-datafusion/testing/data/csv/aggregate_test_100.csv]]}, projection=[c1, c2, c3], has_header=true | | | | +---------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

gruuya · 2023-11-04T15:27:09Z

@alamb thanks for bearing with me here! Yeah, I agree, ideally #8008 gets some kind of a resolution prior to merging this.

gruuya · 2023-11-10T08:50:49Z

Ok, the last commit (8ebdc13) resolves #8008, so I think this might actually be mergable now.

datafusion/proto/proto/datafusion.proto

Co-authored-by: Jonah Gao <jonahgaox@gmail.com>

alamb · 2023-11-10T20:17:10Z

Thank you @gruuya -- this is on my review queue

alamb

Thank you @gruuya -- this looks really nice to me. Thank you 🙏 Thanks for sticking with the qualified Alias stuff. I think that is a much nicer design now

The only thing I saw was a comment that might be out of date and there is now conflict with this PR.

Thanks again and sorry for the delay in review

alamb · 2023-11-12T11:34:12Z

datafusion/optimizer/src/common_subexpr_eliminate.rs

@@ -238,6 +238,16 @@ impl CommonSubexprEliminate {
        let rewritten = pop_expr(&mut rewritten)?;

        if affected_id.is_empty() {
+            // Alias aggregation expressions if they have changed
+            // TODO: This should be handled in `build_recover_project_plan` once qualified aliases


I think this comment is out of date

Yup, removed and merged latest main.

Thanks for your patience on this one! :)

Thanks for your patience on this one! :)

It is I who should be thanking you.

Thanks again @gruuya

gruuya added 4 commits October 30, 2023 07:41

Initial DISTINT ON implementation

deff43f

Merge branch 'main' into distinct-on-implementation

553f87a

Add a couple more tests

04ce375

Add comments in the replace_distinct_aggregate optimizer

148fee2

github-actions bot added sql SQL Planner logical-expr Logical plan and expressions optimizer Optimizer rules sqllogictest SQL Logic Tests (.slt) substrait labels Oct 30, 2023

This comment was marked as resolved.

Sign in to view

gruuya added 3 commits October 30, 2023 11:49

Run cargo fmt to fix CI

26e9082

Make DISTINCT ON planning more robust to support arbitrary selection …

a5cff4e

…expressions

Merge branch 'main' into distinct-on-impl

525523a

gruuya commented Oct 31, 2023

View reviewed changes

gruuya marked this pull request as ready for review October 31, 2023 12:04

gruuya mentioned this pull request Oct 31, 2023

Implement qualified expression alias #8008

Closed

gruuya added 2 commits November 1, 2023 16:59

Merge branch 'main' into distinct-on-impl

5f0a26b

Add DISTINCT ON + join SLT

2730bbd

waynexia added the api change Changes the API exposed to users of the crate label Nov 2, 2023

waynexia reviewed Nov 2, 2023

View reviewed changes

gruuya added 2 commits November 2, 2023 07:24

Handle no DISTINCT ON expressions and extend the docs for the replace…

9b41907

…_distinct_aggregate optimizer

Merge branch 'main' into distinct-on-impl

7c232c8

gruuya force-pushed the distinct-on-impl branch from 8251e56 to 7c232c8 Compare November 2, 2023 08:57

alamb reviewed Nov 2, 2023

View reviewed changes

gruuya added 2 commits November 3, 2023 13:20

Merge branch 'main' into distinct-on-impl

57ffea9

Remove misleading DISTINCT ON SLT comment

5fdbef4

alamb reviewed Nov 4, 2023

View reviewed changes

gruuya added 2 commits November 4, 2023 16:07

Merge branch 'main' into distinct-on-impl

5f0cf19

Add an EXPLAIN SLT for a basic DISTINCT ON query

2ee64cd

gruuya added 4 commits November 6, 2023 19:49

Merge branch 'main' into distinct-on-impl

2bbcd7b

Revise comment in CommonSubexprEliminate::try_optimize_aggregate

5d89700

Merge branch 'main' into distinct-on-impl

8467736

Implement qualified expression alias and extend test coverage

8ebdc13

jonahgao reviewed Nov 10, 2023

View reviewed changes

datafusion/proto/proto/datafusion.proto Outdated Show resolved Hide resolved

gruuya and others added 2 commits November 10, 2023 15:01

Update datafusion/proto/proto/datafusion.proto

d2bc2b4

Co-authored-by: Jonah Gao <jonahgaox@gmail.com>

Accompanying generated changes to alias proto tag revision

e74e1f8

alamb approved these changes Nov 12, 2023

View reviewed changes

gruuya added 2 commits November 12, 2023 20:31

Merge branch 'main' into distinct-on-impl

a912cad

Remove obsolete comment

9f37d8f

alamb merged commit 2185842 into apache:main Nov 13, 2023
22 checks passed

gruuya deleted the distinct-on-impl branch November 13, 2023 15:13

This was referenced Nov 15, 2023

fix regression in the use of name in ProjectionPushdown #8219

Merged

Regression while planning plans with periods in their name like tag.one: Plan("Aggregate requires at least one grouping or aggregate expression") #8223

Closed

matthewgapp mentioned this pull request Jan 11, 2024

matt/feat/recursive ctes/config flag matthewgapp/arrow-datafusion#3

Closed

		LogicalPlan::Distinct(Distinct::All(input)) => input.schema(),
		LogicalPlan::Distinct(Distinct::On(DistinctOn { schema, .. })) => schema,

Implement DISTINCT ON from Postgres #7981

Implement DISTINCT ON from Postgres #7981

Conversation

gruuya commented Oct 30, 2023 • edited Loading

Which issue does this PR close?

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

This comment was marked as resolved.

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gruuya Nov 1, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gruuya Oct 31, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alamb commented Nov 1, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alamb left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gruuya Nov 3, 2023 • edited Loading

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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gruuya Nov 3, 2023 • edited Loading

Choose a reason for hiding this comment

alamb commented Nov 2, 2023

alamb left a comment

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

Choose a reason for hiding this comment

gruuya Nov 4, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gruuya commented Nov 4, 2023 • edited Loading

gruuya commented Nov 10, 2023

alamb commented Nov 10, 2023

alamb left a comment

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

Implement `DISTINCT ON` from Postgres #7981

Implement `DISTINCT ON` from Postgres #7981

gruuya commented Oct 30, 2023 •

edited

Loading

gruuya Nov 1, 2023 •

edited

Loading

gruuya Oct 31, 2023 •

edited

Loading

gruuya Nov 3, 2023 •

edited

Loading

gruuya Nov 3, 2023 •

edited

Loading

gruuya Nov 4, 2023 •

edited

Loading

gruuya commented Nov 4, 2023 •

edited

Loading