PostgreSQL10.0preview功能增強-兩段式索引(約束欄位+附加欄位)

標籤

PostgreSQL , 10.0 , 約束覆蓋索引

---

背景

如果我們有這樣的查詢

select * from tbl where c1=? and c2=? and c3=? and c4=?

我們建立了複合索引達到最好的查詢效能

create index idx on tbl(c1,c2,c3,c4);

同時還有這樣的約束

create unique index idx on tbl (c1,c2);

那麼這樣的場景中，我們就有兩個索引。

PostgreSQL 10.0提供了一個新的功能，可以將這兩個索引合併，只有一個索引的體積，同時支援這兩個場景。。

create unique index idx on tbl (c1,c2) including (c3,c4);

這便是唯一約束+附加欄位組合功能索引

詳見

Hi hackers,  

I`m working on a patch that allows to combine covering and unique   
functionality for btree indexes.  

_Previous discussion was here:_  
1) Proposal thread   
<http://www.postgresql.org/message-id/55F2CCD0.7040608@postgrespro.ru>  
2) Message with proposal clarification   
<http://www.postgresql.org/message-id/55F84DF4.5030207@postgrespro.ru>  

In a nutshell, the feature allows to create index with "key" columns and   
"included" columns.  
"key" columns can be used as scan keys. Unique constraint relates only   
to "key" columns.  
"included" columns may be used as scan keys if they have suitable opclass.  
Both "key" and "included" columns can be returned from index by   
IndexOnlyScan.  

Btree is the default index and it`s used everywhere. So it requires   
properly testing. Volunteers are welcome)  

_Use case:_  
- We have a table (c1, c2, c3, c4);  
- We need to have an unique index on (c1, c2).  
- We would like to have a covering index on all columns to avoid reading   
of heap pages.  

Old way:  
CREATE UNIQUE INDEX olduniqueidx ON oldt USING btree (c1, c2);  
CREATE INDEX oldcoveringidx ON oldt USING btree (c1, c2, c3, c4);  

What`s wrong?  
Two indexes contain repeated data. Overhead to data manipulation   
operations and database size.  

New way:  
CREATE UNIQUE INDEX newidx ON newt USING btree (c1, c2) INCLUDING (c3, c4);  

The patch is attached.  
In `test.sql` you can find a test with detailed comments on each step,   
and comparison of old and new indexes.  

New feature has following syntax:  
CREATE UNIQUE INDEX newidx ON newt USING btree (c1, c2) INCLUDING (c3, c4);  
Keyword INCLUDING defines the "included" columns of index. These columns   
aren`t concern to unique constraint.  
Also, them are not stored in index inner pages. It allows to decrease   
index size.  

_Results:_  
1) Additional covering index is not required anymore.  
2) New index can use IndexOnlyScan on queries, where old index can`t.  

For example,  
explain analyze select c1, c2 from newt where c1<10000 and c3<20;  

*more examples in `test.sql`  

_Future work:_  
To do opclasses for "included" columns optional.  

CREATE TABLE tbl (c1 int, c4 box);  
CREATE UNIQUE INDEX idx ON tbl USING btree (c1) INCLUDING (c4);  

If we don`t need c4 as an index scankey, we don`t need any btree opclass   
on it.  
But we still want to have it in covering index for queries like  

SELECT c4 FROM tbl WHERE c1=1000;  
SELECT * FROM tbl WHERE c1=1000;  

--   
Anastasia Lubennikova  
Postgres Professional:http://www.postgrespro.com  
The Russian Postgres Company  

這個patch的討論，詳見郵件組，本文末尾URL。

PostgreSQL社群的作風非常嚴謹，一個patch可能在郵件組中討論幾個月甚至幾年，根據大家的意見反覆的修正，patch合併到master已經非常成熟，所以PostgreSQL的穩定性也是遠近聞名的。

參考

https://commitfest.postgresql.org/13/961/

https://www.postgresql.org/message-id/flat/56168952.4010101@postgrespro.ru#56168952.4010101@postgrespro.ru