Re: Final Patch for GROUPING SETS - Mailing list pgsql-hackers
From | Andrew Gierth |
---|---|
Subject | Re: Final Patch for GROUPING SETS |
Date | |
Msg-id | 878ulgpfnz.fsf@news-spur.riddles.org.uk Whole thread Raw |
In response to | Re: Final Patch for GROUPING SETS (Marti Raudsepp <marti@juffo.org>) |
Responses |
Re: Final Patch for GROUPING SETS
|
List | pgsql-hackers |
>>>>> "Marti" == Marti Raudsepp <marti@juffo.org> writes: Marti> Since you were asking for feedback on the EXPLAIN output onMarti> IRC, I'd weigh in and say that having the groupson separateMarti> lines would be significantly more readable. I revisited the explain output a bit and have come up with these (surrounding material trimmed for clarity): (text format) GroupAggregate (cost=1122.39..1197.48 rows=9 width=8) Group Key: two, four Group Key: two Group Key: () -> ... (xml format) <Plan> <Node-Type>Aggregate</Node-Type> <Strategy>Sorted</Strategy> <Startup-Cost>1122.39</Startup-Cost> <Total-Cost>1197.48</Total-Cost> <Plan-Rows>9</Plan-Rows> <Plan-Width>8</Plan-Width> <Grouping-Sets> <Group-Key> <Item>two</Item> <Item>four</Item> </Group-Key> <Group-Key> <Item>two</Item> </Group-Key> <Group-Key> </Group-Key> </Grouping-Sets> <Plans>... (json format) "Plan": { "Node Type": "Aggregate", "Strategy": "Sorted", "Startup Cost": 1122.39, "Total Cost": 1197.48, "Plan Rows": 9, "Plan Width": 8, "Grouping Sets": [ ["two", "four"], ["two"], [] ], "Plans": [...] (yaml format) - Plan: Node Type: "Aggregate" Strategy: "Sorted" Startup Cost: 1122.39 Total Cost: 1197.48 Plan Rows: 9 PlanWidth: 8 Grouping Sets: - - "two" - "four" - - "two" - Plans: ... Opinions? Any improvements? I'm not entirely happy with what I had to do with the json and (especially) the YAML output code in order to make this work. There seemed no obvious way to generate nested unlabelled structures in either using the existing Explain* functions, and for the YAML case the best output structure to produce was entirely non-obvious (and trying to read the YAML spec made my head explode). Marti> Do you think it would be reasonable to normalize single-setMarti> grouping sets into a normal GROUP BY? It's certainly possible, though it would seem somewhat odd to write queries that way. Either the parser or the planner could do that; would you want the original syntax preserved in views, or wouldn't that matter? Marti> I'd expect GROUP BY () to be fully equivalent to having noMarti> GROUP BY clause, but there's a difference in explainMarti>output. The former displays "Grouping Sets: ()" which is odd,Marti> since none of the grouping set keywordswere used. That's an implementation artifact, in the sense that we preserve the fact that GROUP BY () was used by using an empty grouping set. Is it a problem, really, that it shows up that way in explain? -- Andrew (irc:RhodiumToad)
pgsql-hackers by date: