BUG #16869: GROUP BY on primary key unnecessarily triggers a full table scan

The following bug has been logged on the website:

Bug reference: 16869
Logged by: Carroll Wainwright
Email address: carroll(at)clwainwright(dot)net
PostgreSQL version: 13.2
Operating system: macos 10.14.6
Description:

I'm trying to do a very simple query with a GROUP BY and an indexed column,
but if I group by the primary key I end up having to do a full table scan
and the indexed column does not get used. Consider the following simple set
up:
```
CREATE TABLE foo (
id serial NOT NULL PRIMARY KEY,
name varchar(100) NOT NULL,
data real NOT NULL
);
INSERT INTO foo (name, data) SELECT
md5(random()::text), random() FROM generate_series(1, 100000);
CREATE INDEX foo_idx ON foo ("data");
```
Then the following query causes a full table scan (about 100ms on my
computer):
```
SELECT id, name, data FROM foo GROUP BY id ORDER BY data LIMIT 10;
```
The EXPLAIN ANALYZE output is:
```
Limit (cost=8755.26..8755.28 rows=10 width=226) (actual
time=103.486..103.495 rows=10 loops=1)
-> Sort (cost=8755.26..9005.26 rows=100000 width=226) (actual
time=103.484..103.489 rows=10 loops=1)
Sort Key: data
Sort Method: top-N heapsort Memory: 26kB
-> Group (cost=0.29..6594.29 rows=100000 width=226) (actual
time=0.037..66.625 rows=100000 loops=1)
Group Key: id
-> Index Scan using foo_pkey on foo (cost=0.29..6344.29
rows=100000 width=226) (actual time=0.033..31.239 rows=100000 loops=1)
Planning Time: 0.158 ms
Execution Time: 103.589 ms
```
Note the index scan on "foo_pkey", which should not be necessary. Obviously,
the grouping doesn't do anything here, but it would if I had joined with
some secondary table on which I wanted to aggregate (which is how I found
this bug in the first place). If I drop the GROUP BY the query executes very
quickly (< 1ms). Interestingly, the following queries *also* execute very
quickly using the index:
```
SELECT name, data FROM foo GROUP BY name, data ORDER BY data LIMIT 10;
SELECT COALESCE(id) as foo_id, name, data FROM foo GROUP BY foo_id, name,
data ORDER BY data LIMIT 10;
```
This last query, which ought to be functionally equivalent to `GROUP BY id`
yields the following execution plan:
```
Limit (cost=67.83..69.38 rows=10 width=226) (actual time=0.139..0.158
rows=10 loops=1)
-> Group (cost=67.83..15636.35 rows=100000 width=226) (actual
time=0.137..0.152 rows=10 loops=1)
Group Key: data, (COALESCE(id)), name
-> Incremental Sort (cost=67.83..14886.35 rows=100000 width=226)
(actual time=0.134..0.137 rows=10 loops=1)
Sort Key: data, (COALESCE(id)), name
Presorted Key: data
Full-sort Groups: 1 Sort Method: quicksort Average Memory:
27kB Peak Memory: 27kB
-> Index Scan using foo_idx on foo (cost=0.29..6344.29
rows=100000 width=226) (actual time=0.028..0.093 rows=33 loops=1)
Planning Time: 0.212 ms
Execution Time: 0.205 ms
```
Note that it's properly using the "foo_idx" index here, and executes very
fast.

So something is going on when grouping by the primary key. This seems like a
bug, or, at the very least, very unintuitive behavior. I didn't see anything
in the documentation implying that this should be expected.

SELECT version() yields:
```
PostgreSQL 13.2 on x86_64-apple-darwin19.6.0, compiled by Apple clang
version 11.0.3 (clang-1103.0.32.62), 64-bit
```
but I first saw this behavior on a PostgreSQL 10 installation, so it's not
new.