FILLFACTOR
Hanya dengan INSERT dan SELECT anda harus menggunakan FILLFACTOR dari 100 di mana-mana.
Tidak ada gunanya meninggalkan ruang gerak per blok memori jika Anda tidak akan "bergoyang" dengan UPDATE s.
Mekanisme di balik FILLFACTOR sangat sederhana. INSERT s hanya mengisi setiap halaman data (biasanya blok 8 kb) hingga persentase yang dinyatakan oleh FILLFACTOR pengaturan. Juga, setiap kali Anda menjalankan VACUUM FULL atau CLUSTER di atas meja, ruang gerak yang sama per blok dibangun kembali. Idealnya, ini memungkinkan UPDATE s untuk menyimpan versi baris baru di halaman data yang sama, yang dapat memberikan peningkatan kinerja yang substansial saat menangani banyak UPDATE s. Juga bermanfaat dalam kombinasi dengan H.O.T. pembaruan :
Jika ada tidak pembaruan, jangan buang ruang untuk ini dan atur FILLFACTOR = 100 .
Sumber informasi dasar:manual tentang CREATE TABLE
atau CREATE INDEX .
Pengoptimalan lainnya
Tapi Anda bisa melakukan sesuatu yang lain - karena Anda tampaknya payah dalam pengoptimalan ... :)
CREATE TABLE dev_transactions
( transaction_id serial PRIMARY KEY,
gateway integer NOT NULL,
moment timestamp NOT NULL,
transaction_type smallint NOT NULL,
status smallint NOT NULL,
device integer NOT NULL,
controler smallint NOT NULL,
token integer,
et_mode character(1));
Ini mengoptimalkan tabel Anda terkait dengan penyelarasan data dan menghindari pengisi untuk server 64 bit biasa dan menyimpan beberapa byte, mungkin rata-rata hanya 8 byte - Anda biasanya tidak dapat memeras banyak dengan "tetris kolom:
Juga, simpan NOT NULL kolom di awal tabel untuk bonus kinerja yang sangat kecil.
Juga, tabel Anda memiliki 9 kolom . Ini berarti tambahan 8 byte untuk NULL bitmap . yang diperluas - yang akan cocok dengan bitmap NULL 1-byte awal hanya untuk 8 kolom .
Jika Anda mendefinisikan et_mode dan token NOT NULL , semua kolom adalah NOT NULL dan bitmap NULL digunakan sama sekali, membebaskan 8 byte.
Ini bahkan berfungsi per baris jika Anda tidak mendeklarasikan kolom NOT NULL . Jika semua kolom memiliki nilai, tidak ada bitmap NULL untuk baris ini. Dalam kasus Anda, ini mengarah pada efek paradoks yang mengisi nilai untuk et_mode dan token dapat membuat ukuran penyimpanan Anda lebih kecil atau setidaknya tetap sama:
Sumber informasi dasar:manual tentang Penyimpanan Fisik Database .
Bandingkan ukuran baris (diisi dengan nilai) dengan tabel asli Anda untuk mendapatkan bukti yang pasti:
SELECT pg_column_size(t) FROM dev_transactions t;
