From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Aditya Toshniwal <aditya(dot)toshniwal(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PG-11] Potential bug related to INCLUDE clause of CREATE INDEX |
Date: | 2018-07-10 13:54:55 |
Message-ID: | 28612.1531230895@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Aditya Toshniwal <aditya(dot)toshniwal(at)enterprisedb(dot)com> writes:
> I am working on a feature to support INCLUDE clause of index in PG-11. As
> per the documentation https://www.postgresql.org/docs/11/static/
> sql-createindex.html, columns listed in INCLUDE clause cannot also be
> present as index key columns. But I find different behaviour for below
> queries which are logically identical.
I wonder why there is any such restriction at all. We have never
attempted to prevent the creation of "silly" indexes, eg
regression=# create table some_table (id int);
CREATE TABLE
regression=# create index on some_table (id,id);
CREATE INDEX
regression=# \d+ some_table
Table "public.some_table"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------+-----------+----------+---------+---------+--------------+-------------
id | integer | | | | plain | |
Indexes:
"some_table_id_id1_idx" btree (id, id)
So my inclination is to rip out the "must not intersect" test altogether,
not try to make it a bit smarter.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2018-07-10 14:35:58 | Re: [HACKERS] WAL logging problem in 9.4.3? |
Previous Message | Ashutosh Bapat | 2018-07-10 13:54:44 | Re: [HACKERS] PoC: full merge join on comparison clause |