Address Marcos' comments

Author: ggevay

doc/developer/design/20230110_window_functions.md

@@ -32,7 +32,9 @@ SELECT sensor_id, time, measurement_value, measurement_value - LAG(measurement_v
 FROM measurements;
 ```
 
-Certain window functions operate on a _window frame_, which is a subset of a partition. The default frame includes the rows from the first row of the partition up to the current row (or more accurately, to the last row of the peer group of the current row, where a peer group is a set of rows that are equal on both the `PARTITION BY` and the `ORDER BY`). For example, all aggregation functions can be used also as window functions (we will refer to this as _window aggregations_), where they aggregate values from inside the current window frame. The following query calculates a running total (prefix sum) of measurement values for each sensor (which wouldn't make sense for a temperature sensor, but makes sense for, e.g., a water flow sensor):
+Throughout the document, we will use the concept of a _peer group_, which is a set of rows that are equal on both the `PARTITION BY` and the `ORDER BY` expressions. For example, in the above query it might happen that a certain sensor has two measurements at the same timestamp (e.g. because the sensor did two measurements in the same second, and the timestamps are rounded to seconds by the time they get to this query).
+
+Certain window functions operate on a _window frame_, which is a subset of a partition. The default frame includes the rows from the first row of the partition up to the current row (or more accurately, to the last row of the peer group of the current row). For example, all aggregation functions can be used also as window functions (we will refer to this as _window aggregations_), where they aggregate values from inside the current window frame. The following query calculates a running total (prefix sum) of measurement values for each sensor (which wouldn't make sense for a temperature sensor, but makes sense for, e.g., a water flow sensor):
 
 ```SQL
 SELECT sensor_id, time, SUM(measurement_value)
@@ -42,7 +44,7 @@ FROM measurements;
 
 Note that this query doesn't compute just one value for each partition. Instead, it calculates a value for each input row: the sum of the same sensor's measurements that happened no later than the current input row.
 
-We can also explicitly specify a frame, i.e., how far it extends from the current row, both backwards and forwards. One option is to say `UNBOUNDED PRECEDING` or `UNBOUNDED FOLLOWING`, meaning that the frame extends to the beginning or end of the current partition. Another option is to specify an offset. For example, the following query computes a moving average (e.g., to have a smoother curve when we want to plot it or when we want less noise for an alerting use case):
+We can also explicitly specify a frame, i.e., how far it extends from the current row, both backwards and forwards (only within the same partition). One option is to say `UNBOUNDED PRECEDING` or `UNBOUNDED FOLLOWING`, meaning that the frame extends to the beginning or end of the current partition. Another option is to specify an offset. For example, the following query computes a moving average (e.g., to have a smoother curve when we want to plot it or when we want less noise for an alerting use case):
 
 ```SQL
 SELECT sensor_id, time, AVG(measurement_value)