Hi,
If you only need first/last values, and your lists are short (smaller than max_allowed_packet, given group_concat_max_len is max allowed packet) then group_concat works fine.
Window functions work /on the result set/ itself. They are kind of like sub select over the entire result of the SELECT statement, something a subquery in the SELECT clause is unable to do. As such window functions are not usually combined with GROUP BY.
This is because window functions let you see the detail and the summary at the same time. They are kind of like spreadsheet expressions in that way.
For example:
SELECT date,value,last_value(value) over (partition by date order by value asc),first_value(value) over(partition by date),
sum(value) over (partition by date),
lag(value,2) over (partition by date)
From table
Shard-Query always stores the resultset in a table, so it can update the table for each window function result, which is calculated by a query. You can look at the wf_* functions in shard-query for an implementation of each window function. You could even add your own if you like. If there is interest I can make that pluggable.
You can see lots of examples in the test directory too, and s simple test data set.
--justin
Sent from my iPhone
hum i'm thinking about the problem
for example if we have an COUNT(*) or a SUM(value) or MAX(value) or MIN(value) or anyother functions
shouldn't be more rational allow the 'single thread' query execute and use the GROUP_CONCAT function?
ok it's not multi thread, but could the group_concat with limit 'optimize' the shard query or single queries like this?