Search Postgresql Archives

Re: Why scan all columns when we select distinct c1?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Jan 14, 2024 at 6:18 AM Yongtao Huang <yongtaoh2022@xxxxxxxxx> wrote:
PostgreSQL version: 16.1
Operating system:   centos7
Description:       

Let me show these explain results first, in PG9.4 and PG16.1.

### Behavior in PG9.4
``` SQL
gpadmin=# create table t1 (c1 int, c2 text);
CREATE TABLE
gpadmin=# explain (costs off, verbose) select distinct c1 from t1;
         QUERY PLAN
-----------------------------
 HashAggregate
   Output: c1
   Group Key: t1.c1
   ->  Seq Scan on public.t1
         Output: c1 <---- pay attention <----  !!!
(5 rows)
```

### Behavior in PG 16.1
``` SQL
gpadmin=# create table t1 (c1 int, c2 text);
CREATE TABLE
gpadmin=# explain (costs off, verbose) select distinct c1 from t1;
         QUERY PLAN
-----------------------------
 HashAggregate
   Output: c1
   Group Key: t1.c1
   ->  Seq Scan on public.t1
         Output: c1, c2  <---- pay attention <---- !!!
(5 rows)
```

My question is why scan all columns in PG 16.01?
If `select distinct c1`, scan the column `c1` is enough, like PG 9.4.
 
You can't scan just one column of a row-oriented table. 

The real question is why it mentions c2.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux