Menghitung dan menghemat ruang di PostgreSQL

"Tetris Kolom"

Sebenarnya, Anda dapat melakukan sesuatu , tetapi ini membutuhkan pemahaman yang lebih dalam. Kata kuncinya adalah pading perataan . Setiap tipe data memiliki persyaratan penyelarasan tertentu.

Anda dapat meminimalkan ruang yang hilang untuk mengisi antar kolom dengan memesan mereka dengan baik. Contoh (ekstrim) berikut akan menghabiskan banyak ruang disk fisik:

CREATE TABLE t (
    e int2    -- 6 bytes of padding after int2
  , a int8
  , f int2    -- 6 bytes of padding after int2
  , b int8
  , g int2    -- 6 bytes of padding after int2
  , c int8
  , h int2    -- 6 bytes of padding after int2
  , d int8)

Untuk menghemat 24 byte per baris, gunakan sebagai gantinya:

CREATE TABLE t (
    a int8
  , b int8
  , c int8
  , d int8
  , e int2
  , f int2
  , g int2
  , h int2)   -- 4 int2 occupy 8 byte (MAXALIGN), no padding at the end

db<>main biola di sini
_{sqlfiddle lama}

Sebagai aturan praktis, jika Anda menempatkan kolom 8-byte terlebih dahulu, kemudian kolom 4-byte, 2-byte, dan 1-byte terakhir, Anda tidak akan salah.

boolean , uuid (!) dan beberapa jenis lainnya tidak memerlukan bantalan pelurusan. text , varchar dan jenis "varlena" (panjang variabel) lainnya secara nominal memerlukan penyelarasan "int" (4 byte pada sebagian besar mesin). Tapi saya mengamati tidak ada padding penyelarasan dalam format disk (tidak seperti di RAM). Akhirnya, saya menemukan penjelasannya di catatan di kode sumber:

Perhatikan juga bahwa kami mengizinkan penyelarasan nominal dilanggar saat menyimpan varlena "dikemas"; mekanisme TOAST menangani penyembunyian itu dari sebagian besar kode.

Jadi penyelarasan "int" hanya diterapkan ketika datum (mungkin dikompresi) termasuk satu byte panjang utama melebihi 127 byte. Kemudian penyimpanan varlena beralih ke empat byte terdepan dan memerlukan penyelarasan "int".

Biasanya, Anda dapat menyimpan beberapa byte per baris saat memainkan "column tetris" terbaik . Tak satu pun dari ini diperlukan dalam banyak kasus. Tetapi dengan miliaran baris, ini bisa berarti beberapa gigabyte dengan mudah.

Anda dapat menguji ukuran kolom/baris yang sebenarnya dengan fungsi pg_column_size() .
Beberapa jenis menempati lebih banyak ruang di RAM daripada di disk (format terkompresi atau "dikemas"). Anda bisa mendapatkan hasil yang lebih besar untuk konstanta (format RAM) daripada kolom tabel saat menguji nilai yang sama (atau baris nilai vs. baris tabel) dengan pg_column_size() .

Terakhir, beberapa jenis dapat dikompresi atau "dipanggang" (disimpan di luar jalur) atau keduanya.

Overhead per tupel (baris)

4 byte per baris untuk pengidentifikasi item - tidak tunduk pada pertimbangan di atas.
Dan setidaknya 24 byte (23 + padding) untuk header tuple. Panduan Tata Letak Halaman Basis Data:

Ada header berukuran tetap (menempati 23 byte pada sebagian besar mesin), diikuti oleh bitmap nol opsional, bidang ID objek opsional, dan data pengguna.

Untuk padding antara header dan data pengguna, Anda perlu mengetahui MAXALIGN di server Anda - biasanya 8 byte pada OS 64-bit (atau 4 byte pada OS 32-bit). Jika Anda tidak yakin, lihat pg_controldata .

Jalankan yang berikut ini di direktori biner Postgres untuk mendapatkan jawaban yang pasti:

./pg_controldata /path/to/my/dbcluster

Panduan:

Data pengguna yang sebenarnya (kolom dari baris) dimulai pada offset yang ditunjukkan oleh t_hoff , yang harus selalu kelipatan dari MAXALIGN jarak untuk peron.

Jadi, Anda biasanya mendapatkan penyimpanan yang optimal dengan mengemas data dalam kelipatan 8 byte.

Tidak ada untungnya dalam contoh yang Anda posting . Sudah dikemas rapat. 2 byte padding setelah int2 terakhir , 4 byte di akhir. Anda dapat menggabungkan padding hingga 6 byte di akhir, yang tidak akan mengubah apa pun.

Overhead per halaman data

Ukuran halaman data biasanya 8 KB. Beberapa overhead / mengasapi pada tingkat ini, juga:Sisa tidak cukup besar untuk memuat tupel lain, dan yang lebih penting baris mati atau persentase dicadangkan dengan FILLFACTOR pengaturan.

Ada beberapa faktor lain untuk ukuran pada disk yang perlu dipertimbangkan:

• Berapa banyak catatan yang dapat saya simpan dalam 5 MB PostgreSQL di Heroku?
• Apakah tidak menggunakan NULL di PostgreSQL masih menggunakan bitmap NULL di header?
• Mengonfigurasi PostgreSQL untuk kinerja membaca

Jenis larik?

Dengan larik ketik seperti yang Anda evaluasi, Anda akan menambahkan 24 byte overhead untuk jenisnya. Plus, elemen array menempati ruang seperti biasa. Tidak ada untungnya di sana.