agora inbox for pgsql-sql@postgresql.org
help / color / mirror / Atom feedFrom: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: Rocky Ji <rockyji3438@gmail.com>
Cc: pgsql-sql@lists.postgresql.org
Subject: Re: Why does GROUP BY reduce number of rows?
Date: Fri, 01 Mar 2019 13:25:53 +0000
Message-ID: <87y35yd9ul.fsf@news-spur.riddles.org.uk> (raw)
In-Reply-To: <CAN2Gq-S_TSjGg0Aoygz6SWNgJY3+sf1mwuenpPjAhj8qLs7OBA@mail.gmail.com>
References: <CAN2Gq-S_TSjGg0Aoygz6SWNgJY3+sf1mwuenpPjAhj8qLs7OBA@mail.gmail.com>
>>>>> "Rocky" == Rocky Ji <rockyji3438@gmail.com> writes:
Rocky> Let's call this error/mistake a "UDFS" (Unintended Deviation
Rocky> From Standards).
What deviation? If the standard leaves something unspecified, the
PostgreSQL can choose to do as it pleases. (We can also choose to just
violate the standard...)
Rocky> I think: reduction in number of rows in output when `GROUP BY`
Rocky> clause is used is another UDFS.
Reducing the number of rows of output is the SOLE PURPOSE AND REASON TO
EXIST of the GROUP BY clause. By definition, the clause produces only
one output row for each matching group in the input.
The rows produced by GROUP BY are also not "the final row" or even "the
first row" of the group. They are _new_ rows computed from column
expressions which must reference the input in only two ways:
- aggregate functions computed over the input group
- values which can be proved by the implementation to be guaranteed to
be the same in all rows of the input group (that is, the grouping
columns themselves and anything the implementation can prove is a
functional dependency of the grouping columns).
Some other databases may be lax about enforcing these restrictions and
allow non-dependent columns to be included in the result, taking their
values from some arbitrary row of the input group. PG if anything is
_too_ strict about this, since for implementation reasons we can prove
functional dependency only in very limited cases and we reject anything
else.
Rocky> What if important (i.e. "uniquely identifying" for "human eyes")
Rocky> data was contained in first row of a group. Why does the
Rocky> underlying program (psql server, I suppose) **decide** that
Rocky> preceding rows are not worth displaying?
The person who wrote GROUP BY in the query made that decision.
BTW, if you want to calculate aggregated values across rows without
reducing the number of rows of output, there's an entirely separate
mechanism for that: window functions.
--
Andrew (irc:RhodiumToad)
view thread (2+ messages)
Message-ID: <87y35yd9ul.fsf@news-spur.riddles.org.uk>
Permalink: ../87y35yd9ul.fsf@news-spur.riddles.org.uk/
Also on: postgresql.org/message-id/87y35yd9ul.fsf@news-spur.riddles.org.uk
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: andrew@tao11.riddles.org.uk, rockyji3438@gmail.com, pgsql-sql@lists.postgresql.org
Subject: Re: Why does GROUP BY reduce number of rows?
In-Reply-To: <87y35yd9ul.fsf@news-spur.riddles.org.uk>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox