PostgreSQL
 sql >> Teknologi Basis Data >  >> RDS >> PostgreSQL

Memahami ukuran baris Postgres

Perhitungan ukuran baris jauh lebih rumit dari itu.

Penyimpanan biasanya dipartisi dalam halaman data8 kB . Ada overhead tetap kecil per halaman, kemungkinan sisa yang tidak cukup besar untuk memuat tupel lain, dan yang lebih penting adalah baris mati atau persentase yang awalnya dipesan dengan FILLFACTOR pengaturan.

Dan bahkan ada lebih banyak overhead per baris (tuple):pengenal item 4 byte di awal halaman, HeapTupleHeader dari 23 byte dan pading perataan . Awal tajuk tuple serta awal data tupel disejajarkan pada kelipatan MAXALIGN , yaitu 8 byte pada mesin 64-bit biasa. Beberapa tipe data memerlukan penyelarasan ke kelipatan 2, 4, atau 8 byte berikutnya.

Mengutip manual pada tabel sistem pg_tpye :

typalign adalah penyelarasan yang diperlukan saat menyimpan nilai jenis ini. Ini berlaku untuk penyimpanan di disk serta sebagian besar representasi nilai di dalam PostgreSQL. Ketika beberapa nilai disimpan secara berurutan, seperti dalam representasi baris lengkap pada disk, padding dimasukkan sebelum datum jenis ini sehingga dimulai pada batas yang ditentukan. Referensi keselarasan adalah awal dari datum pertama dalam urutan.

Nilai yang mungkin adalah:

  • c =char penyelarasan, yaitu, tidak diperlukan penyelarasan.

  • s =short keselarasan (2 byte pada sebagian besar mesin).

  • i =int keselarasan (4 byte pada kebanyakan mesin).

  • d =double keselarasan (8 byte pada banyak mesin, tetapi tidak semuanya).

Baca tentang dasar-dasar dalam manual di sini.

Contoh Anda

Ini menghasilkan 4 byte padding setelah 3 integer kolom, karena timestamp kolom membutuhkan double penyelarasan dan harus dimulai pada kelipatan 8 byte berikutnya.

Jadi, satu baris menempati:

   23   -- heaptupleheader
 +  1   -- padding or NULL bitmap
 + 12   -- 3 * integer (no alignment padding here)
 +  4   -- padding after 3rd integer
 +  8   -- timestamp
 +  0   -- no padding since tuple ends at multiple of MAXALIGN

Pengenal item plus per tuple di header halaman (seperti yang ditunjukkan oleh @A.H. di komentar):

 +  4   -- item identifier in page header
------
 = 52 bytes

Jadi kita sampai pada 52 byte yang diamati .

Perhitungan pg_relation_size(tbl) / count(*) adalah perkiraan pesimis. pg_relation_size(tbl) termasuk mengasapi (baris mati) dan ruang yang disediakan oleh fillfactor , serta overhead per halaman data dan per tabel. (Dan kami bahkan tidak menyebutkan kompresi untuk varlena long yang panjang data dalam tabel TOAST, karena tidak berlaku di sini.)

Anda dapat menginstal modul tambahan pgstattuple dan memanggil SELECT * FROM pgstattuple('tbl_name'); untuk informasi lebih lanjut tentang tabel dan ukuran tupel.

Terkait:

  • Ukuran tabel dengan tata letak halaman
  • Menghitung dan menghemat ruang di PostgreSQL


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Postgres - Ubah daftar adjacency menjadi objek JSON bersarang

  2. Django+Postgres:transaksi saat ini dibatalkan, perintah diabaikan hingga akhir blok transaksi

  3. Mengkompilasi ekstensi mongo_fdw yang dapat ditulis pada format biner instalasi PostgreSQL.

  4. Cara Menggunakan Fungsi Substring di PostgreSQL dan Redshift

  5. PostgreSQL SHOW TABLES Setara (psql)