Apa urutan catatan dalam tabel dengan kunci primer komposit?

Pertanyaan ini membuat asumsi yang salah arah bahwa kunci utama memaksakan urutan tabel sama sekali. Tidak. Tabel PostgreSQL tidak memiliki urutan yang ditentukan, dengan atau tanpa kunci utama; mereka adalah "tumpukan" baris yang disusun dalam blok halaman. Pemesanan dilakukan dengan menggunakan ORDER BY klausa kueri bila diinginkan.

Anda mungkin berpikir bahwa tabel PostgreSQL disimpan sebagai tabel berorientasi indeks yang disimpan di disk dalam urutan kunci utama, tetapi bukan itu cara kerja Pg. Saya pikir InnoDB menyimpan tabel yang diatur oleh kunci utama (tetapi belum diperiksa), dan itu opsional di beberapa database vendor lain menggunakan fitur yang sering disebut "indeks berkerumun" atau "tabel yang diatur indeks". Fitur ini saat ini tidak didukung oleh PostgreSQL (setidaknya pada 9.3).

Yang mengatakan, PRIMARY KEY diimplementasikan menggunakan UNIQUE index, dan ada pemesanan ke index itu. Itu diurutkan dalam urutan menaik dari kolom kiri indeks (dan karena itu kunci utama) dan seterusnya, seolah-olah itu ORDER BY col1 ASC, col2 ASC, col3 ASC; . Hal yang sama berlaku untuk indeks b-tree lainnya (berbeda dari GiST atau GIN) di PostgreSQL, karena diimplementasikan menggunakan b+trees.

Jadi di tabel:

CREATE TABLE demo (
   a integer,
   b text, 
   PRIMARY KEY(a,b)
);

sistem akan secara otomatis membuat yang setara dengan:

CREATE UNIQUE INDEX demo_pkey ON demo(a ASC, b ASC);

Ini dilaporkan kepada Anda saat Anda membuat tabel, misalnya:

regress=>     CREATE TABLE demo (
regress(>        a integer,
regress(>        b text, 
regress(>        PRIMARY KEY(a,b)
regress(>     );
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "demo_pkey" for table "demo"
CREATE TABLE

Anda dapat melihat indeks ini saat memeriksa tabel:

regress=> \d demo
     Table "public.demo"
 Column |  Type   | Modifiers 
--------+---------+-----------
 a      | integer | not null
 b      | text    | not null
Indexes:
    "demo_pkey" PRIMARY KEY, btree (a, b)

Anda dapat CLUSTER pada indeks ini untuk menyusun ulang tabel sesuai dengan kunci utama, tetapi ini adalah operasi satu kali. Sistem tidak akan mempertahankan pemesanan itu - meskipun jika ada ruang kosong di halaman karena FILLFACTOR non-default Saya pikir itu akan mencoba.

Salah satu konsekuensi dari pengurutan inheren indeks (tetapi bukan heap) adalah banyak lebih cepat untuk mencari:

SELECT * FROM demo ORDER BY a, b;
SELECT * FROM demo ORDER BY a;

dari:

SELECT * FROM demo ORDER BY a DESC, b;

dan keduanya tidak dapat menggunakan indeks kunci utama sama sekali, mereka akan melakukan seqscan kecuali Anda memiliki indeks di b :

SELECT * FROM demo ORDER BY b, a;
SELECT * FROM demo ORDER BY b;

Ini karena PostgreSQL dapat menggunakan indeks pada (a,b) hampir secepat indeks pada (a) sendiri. Itu tidak dapat menggunakan indeks pada (a,b) seolah-olah itu adalah indeks pada (b) sendiri - tidak pelan-pelan, tidak bisa.

Adapun DESC entri, untuk itu Pg yang satu harus melakukan pemindaian indeks terbalik, yang lebih lambat dari pemindaian indeks maju biasa. Jika Anda melihat banyak pemindaian indeks terbalik di EXPLAIN ANALYZE dan Anda dapat membayar biaya kinerja indeks ekstra Anda dapat membuat indeks pada bidang di DESC pesan.

Ini berlaku untuk WHERE klausa, bukan hanya ORDER BY . Anda dapat menggunakan indeks pada (a,b) untuk mencari WHERE a = 4 atau WHERE a = 4 AND b = 3 tapi tidak untuk mencari WHERE b = 3 sendiri.