Mengikuti pertemuan "PostgreSQL 11 Fitur Baru"

Hari ini kita akan berbicara tentang fitur-fitur terpenting PostgreSQL 11. Mengapa hanya tentang mereka - karena tidak semua orang membutuhkan beberapa fitur, jadi kami memilih yang paling populer.

Isi

• Kompilasi Jit
• Partisi
• Indeks
• Meliputi Indeks
• SP GiST
• Performa
• WAL
• Cadangkan dan replikasi
• Untuk dba
• Eksekusi paralel
• Pengoptimal
• Fungsi jendela
• Perubahan Pencarian Teks Lengkap
• Json (b) dan teks lengkap
• Prosedur PL / *
• pgbench
• Peningkatan PSQL

Kompilasi Jit

PostgreSQL akhirnya memperkenalkan kompilasi JIT, yaitu, mengkompilasi kueri ke dalam kode biner. Untuk melakukan ini, kompilasi PostgreSQL dengan dukungan untuk kompilasi JIT (Compile time 1 (--with-llvm)) . Pada saat yang sama, mesin harus memiliki versi LLVM tidak lebih rendah dari 3,9.

Apa yang bisa mempercepat JIT?

• Kueri dengan klausa WHERE, yaitu segala sesuatu yang muncul setelah kata kunci ini. Ini tidak selalu diperlukan, tetapi kesempatan itu bermanfaat.
• Perhitungan daftar target: dalam terminologi PostgreSQL, ini adalah semua yang ada di antara pilih dan dari.
• Agregat.
• Konversi rekaman dari satu tampilan ke tampilan lainnya (Proyeksi). Misalnya, saat Anda menerapkan penggabungan ke dua tabel, hasilnya adalah tupel baru yang berisi bidang dari kedua tabel.
• Tuple merusak bentuk. Salah satu masalah dari setiap basis data, setidaknya huruf kecil, relasional, adalah bagaimana cara mendapatkan bidang dari catatan pada disk. Bagaimanapun, mungkin ada nol, mereka memiliki catatan berbeda dan secara umum, ini bukan operasi termurah.

Compile time 2 berarti bahwa JIT tidak digunakan. Dalam PostgreSQL ada saat perencanaan permintaan, ketika sistem memutuskan apa yang bernilai JIT dan apa yang tidak. Pada titik ini, itu JIT dan kemudian eksekutor mengeksekusi apa adanya.

JIT dibuat pluggable. Secara default, ini bekerja dengan LLVM, tetapi Anda dapat menghubungkan JIT lainnya.



Jika Anda mengkompilasi PostgreSQL tanpa dukungan JIT, maka pengaturan pertama tidak berfungsi. Opsi yang diterapkan untuk pengembang, ada pengaturan untuk fungsi JIT individu.

Titik halus berikutnya terkait dengan jit_above_cost. JIT sendiri tidak gratis. Oleh karena itu, PostgreSQL default ke optimasi JIT jika biaya kueri melebihi 100 ribu burung beo bersyarat, di mana menjelaskan, menganalisis, dan sebagainya diukur. Nilai ini dipilih secara acak, jadi perhatikanlah.

Tetapi tidak selalu setelah menyalakan JIT semuanya bekerja segera. Biasanya, semua orang mulai bereksperimen dengan JIT menggunakan pilih * dari tabel di mana id = 600 permintaan dan mereka gagal. Mungkin, perlu untuk mempersulit permintaan, dan kemudian semua orang membuat basis data raksasa dan menyusun permintaan. Akibatnya, PostgreSQL bersandar pada kemampuan disk, tidak memiliki kapasitas buffer dan cache bersama.

Ini adalah contoh yang sepenuhnya abstrak. Ada 9 bidang nol dengan frekuensi berbeda, sehingga Anda dapat melihat efek deformasi tuple.

select i as x1,
case when i % 2 = 0 then i else null end as x2,
case when i % 3 = 0 then i else null end as x3,
case when i % 4 = 0 then i else null end as x4,
case when i % 5 = 0 then i else null end as x5,
case when i % 6 = 0 then i else null end as x6,
case when i % 7 = 0 then i else null end as x7,
case when i % 8 = 0 then i else null end as x8,
case when i % 9 = 0 then i else null end as x9
into t
from generate_series(0, 10000000) i;

vacuum t;
analyze t;

PostgreSQL memiliki banyak kemungkinan, dan untuk melihat kelebihan JIT, nonaktifkan dua baris pertama agar tidak mengganggu, dan setel ulang ambangnya.

set max_parallel_workers=0;
set max_parallel_workers_per_gather=0;
set jit_above_cost=0;
set jit_inline_above_cost=0;
set jit_optimize_above_cost=0;

Ini permintaannya sendiri:

set jit=off;
explain analyze
select count(*) from t where
sqrt(pow(x9, 2) + pow(x8,2)) < 10000;

set jit=on;
explain analyze
select count(*) from t where
sqrt(pow(x9, 2) + pow(x8,2)) < 10000;

Dan inilah hasilnya:

Planning Time: 0.71 ms
Execution Time: 1986.323 ms

VS

Planning Time: 0.060 ms
JIT:
Functions: 4
Generation Time: 0.911 ms
Inlining: true
Inlining Time: 23.876 ms
Optimization: true
Optimization Time: 41.399 ms
Emission Time: 21.856 ms
Execution Time: 949.112 ms

JIT membantu mempercepat permintaan hingga setengahnya. Merencanakan waktu adalah tentang hal yang sama, tetapi ini kemungkinan besar merupakan hasil dari cache PostgreSQL, jadi abaikan saja.

Jika disimpulkan, dibutuhkan sekitar 80 ms untuk kompilasi JIT. Mengapa JIT tidak gratis? Sebelum menjalankan permintaan, Anda perlu mengompilasinya, dan ini juga membutuhkan waktu. Dan tiga urutan besarnya lebih dari perencanaan. Bukan kesenangan yang mahal, tetapi terbayar karena lamanya eksekusi.

Dengan cara ini Anda dapat menggunakan JIT, meskipun itu tidak selalu bermanfaat.

Partisi

Jika Anda memperhatikan partisi di PostgreSQL, Anda mungkin memperhatikan bahwa partisi itu dibuat untuk pertunjukan. Situasi sedikit membaik di versi 10, ketika deklarasi deklarasi partisi (bagian) muncul. Di sisi lain, semuanya tetap sama di dalam dan bekerja kurang lebih sama dengan di versi sebelumnya, yaitu, buruk.
Dalam banyak hal, masalah ini diselesaikan oleh modul pg_pathman, yang memungkinkan bekerja dengan bagian-bagian dan memotongnya pada waktu yang cukup optimal saat run time.

Di versi 11, partisi sangat ditingkatkan:

• Pertama, tabel partisi mungkin memiliki kunci utama, yang harus menyertakan kunci partisi. Sebenarnya, ini adalah kunci semi-primer, atau semi-kunci primer. Sayangnya, Anda tidak dapat membuat kunci asing di dalamnya. Saya harap ini akan diperbaiki di masa depan.
• Juga sekarang dimungkinkan untuk mempartisi tidak hanya oleh rentang, tetapi juga dengan daftar dan hash. Hash cukup primitif, sisa ekspresi diambil untuk itu.
• Saat memperbarui, garis bergerak di antara bagian. Sebelumnya, Anda harus menulis pemicu, tetapi sekarang hal itu dilakukan secara otomatis.

Pertanyaan besarnya adalah: berapa banyak bagian yang bisa saya miliki? Jujur, dengan sejumlah besar bagian (ribuan dan puluhan ribu) fitur tidak berfungsi dengan baik. Pg_pathman lebih baik.

Juga membuat bagian secara default. Sekali lagi, di pg_pathman Anda dapat membuat bagian secara otomatis, yang lebih nyaman. Di sini, semua yang tidak bisa didorong di suatu tempat jatuh di bagian. Jika dalam sistem nyata untuk melakukan ini secara default, maka setelah beberapa waktu Anda mendapatkan kekacauan seperti itu, yang kemudian Anda siksa untuk menyapu.

PostgreSQL 11 sekarang dapat mengoptimalkan partisi jika dua tabel digabungkan dengan kunci partisi dan skema partisi cocok. Ini dikendalikan oleh parameter khusus, yang dimatikan secara default.

Anda dapat menghitung agregat untuk setiap bagian secara terpisah, dan kemudian menambahkannya. Akhirnya, Anda bisa membuat indeks pada tabel partisi induk, dan kemudian indeks lokal di semua tabel yang terhubung dengannya akan dibuat.

Di bagian "Apa yang Baru", hal yang luar biasa disebutkan - kemampuan untuk membuang bagian saat melakukan permintaan. Mari kita periksa cara kerjanya. Hasilnya adalah tabel seperti itu:



Kami membuat tipe dan tabel dua kolom dengan kunci utama, dengan kolom bigserial, menyisipkan data. Kami membuat tabel kedua, yang akan dipartisi dan akan menjadi salinan yang pertama. Tambahkan kunci utama ke tabel dipartisi.



Tabel akan terdiri dari dua jenis entri: "pengasuh perempuan" dan "pengemudi laki-laki". Dan akan ada satu pengemudi wanita. Kami membuat dua bagian, bagi berdasarkan daftar, tambahkan kunci utama dan masukkan semua data dari tabel di mana semua ini dihasilkan. Hasilnya benar-benar tidak menarik:



Perhatikan permintaan itu. Kami memilih semuanya dari tabel yang tidak dipartisi, terhubung ke yang dipartisi. Kami mengambil sepotong kecil dan hanya memilih satu jenis, mereka pergi melalui satu. Kami menunjukkan bahwa kolom oss harus memiliki satu nilai. Ternyata pilihan driver solid.

Pada eksekusi, kami secara khusus menonaktifkan paralelisasi, karena PostgreSQL 11 secara default sangat memparalelkan kueri yang kurang lebih kompleks. Jika kita melihat rencana pelaksanaan (menjelaskan analisis), maka dapat dilihat bahwa sistem menambahkan data di kedua bagian: di pengasuh dan di driver, meskipun pengasuh tidak ada di sana. Tidak ada panggilan ke buffer. Waktu yang dihabiskan, syarat digunakan, meskipun PostgreSQL bisa memikirkan semuanya. Yaitu, deklarasi penghapusan partisi tidak berfungsi segera. Mungkin di build berikutnya ini akan diperbaiki. Dalam hal ini, modul pg_pathman dalam kasus ini berfungsi tanpa masalah.

Indeks

• Optimasi penawaran dengan cara yang monoton, mis. B-tree. Semua orang tahu bahwa ketika Anda memasukkan data yang tumbuh secara monoton, hasilnya tidak terlalu cepat. Sekarang PostgreSQL dapat me-cache halaman akhir dengan cara khusus dan tidak pergi jauh dari root untuk menyisipkan. Ini secara signifikan mempercepat pekerjaan.
• PostgreSQL 10 memungkinkan untuk menggunakan indeks hash karena mulai menggunakan WAL (tulis log depan). Sebelumnya, kami mendapat nilai, membuka kunci halaman, mengembalikan nilainya. Untuk nilai selanjutnya, Anda harus memblokir kembali halaman, kembali, membuka kunci, dan sebagainya. Sekarang hash menjadi lebih cepat. Ini memungkinkan Anda untuk memblokir halaman sekaligus untuk mengambil catatan dari indeks hash, mengembalikan semua nilai dari sana dan membukanya. Sekarang ini diimplementasikan untuk HASH, GiST dan GIN. Di masa depan, ini mungkin akan diterapkan untuk SP-GiST. Tetapi untuk BRIN dengan logika min / max ini pada prinsipnya tidak dapat dilakukan.
• Jika Anda terbiasa membuat indeks fungsional, maka pembaruan HOT (Heap Only Tuple) secara efektif dinonaktifkan. Ketika catatan diperbarui di PostgreSQL, salinan baru benar-benar dibuat, dan ini membutuhkan menempelkan ke semua indeks yang ada di tabel sehingga nilai baru menunjuk ke tuple baru. Optimalisasi semacam itu telah diimplementasikan untuk waktu yang lama: jika pembaruan tidak mengubah bidang yang tidak termasuk dalam indeks, dan ada ruang kosong di halaman yang sama, maka indeks tidak diperbarui, dan dalam versi tuple lama, penunjuk ke versi baru diletakkan. Ini memungkinkan Anda untuk sedikit mengurangi keparahan masalah dengan pembaruan. Namun, pengoptimalan tersebut tidak berfungsi sama sekali jika Anda memiliki indeks fungsional. Di PostgreSQL 11, itu mulai berfungsi. Jika Anda membuat indeks fungsional dan memperbarui tupel yang tidak mengubah apa yang bergantung pada indeks fungsional, maka pembaruan HOT akan berfungsi.

Meliputi Indeks

Fungsionalitas ini diimplementasikan oleh PostgresPro tiga tahun lalu, dan selama ini PostgreSQL mencoba menambahkannya. Menutupi indeks berarti bahwa Anda dapat menambahkan kolom tambahan ke indeks unik, langsung di tuple indeks.

Mengapa Semua orang menyukai pemindaian hanya indeks untuk pekerjaan cepat mereka. Untuk ini, indeks “penutup” bersyarat dibangun:



Tetapi pada saat yang sama, Anda perlu mempertahankan keunikan. Oleh karena itu, dua indeks sedang dibangun, sempit dan lebar.
Kerugiannya adalah bahwa ketika Anda menerapkan vakum, masukkan atau perbarui ke sebuah tabel, Anda harus memperbarui kedua indeks. Jadi memasukkan ke dalam indeks adalah operasi yang lambat. Dan indeks penutup akan memungkinkan untuk mengelola hanya satu indeks.

Benar, ia memiliki beberapa keterbatasan. Lebih tepatnya, manfaat yang mungkin tidak langsung dipahami. Kolom c dan d dalam indeks buat pertama tidak harus berupa tipe skalar yang menentukan indeks b-tree. Artinya, mereka belum tentu memiliki perbandingan yang lebih-kurang. Itu bisa berupa poin atau poligon. Satu-satunya hal adalah bahwa tuple harus kurang dari 2,7 Kb, karena tidak ada pemanggangan dalam indeks, tetapi Anda dapat memasukkan apa yang tidak dapat dibandingkan.

Namun, di dalam indeks dengan kolom yang dijamin ini, tidak ada perhitungan yang dilakukan saat mencari. Ini harus dilakukan dengan filter yang berdiri di atas indeks. Di satu sisi, mengapa tidak menghitungnya di dalam indeks, di sisi lain, ini adalah panggilan fungsi tambahan. Tapi semuanya tidak seseram kelihatannya.

Nah, di samping itu, Anda dapat menambahkan kolom tertutup ini ke kunci utama.

SP GiST

Hanya sedikit orang yang menggunakan indeks ini karena ini cukup spesifik. Namun demikian, menjadi mungkin untuk menyimpan di dalamnya tidak cukup apa yang dimasukkan. Ini mengacu pada lossy - index, kompresi. Ambil poligon sebagai contoh. Sebagai gantinya, kotak pembatas dimasukkan ke dalam indeks, yaitu, persegi panjang minimum yang berisi poligon yang diinginkan. Dalam hal ini, kami mewakili persegi panjang sebagai titik dalam ruang empat dimensi, dan kemudian kami bekerja dengan quad3 klasik, dalam ruang empat dimensi.

Juga untuk SP-GiST memperkenalkan operasi "pencarian awalan". Ini mengembalikan true jika satu baris adalah awalan dari yang lain. Mereka memperkenalkannya bukan hanya seperti itu, tetapi demi permintaan seperti itu dengan dukungan untuk SP-GiST.

SELECT * FROM table WHERE c ^@ „abc“

Dalam b-tree ada batas 2,7 Kb per baris, tetapi SP-GiST tidak. Benar, PostgreSQL memiliki batasan: nilai tunggal tidak boleh melebihi 1 GB.

Performa

• Indeks hanya memindai bitmap telah muncul . Ini berfungsi sama dengan hanya memindai indeks klasik, kecuali bahwa itu tidak dapat menjamin pesanan apa pun. Oleh karena itu, ini hanya berlaku untuk beberapa agregat seperti hitungan (*), karena bitmap tidak dapat mentransfer bidang dari indeks ke pelaksana. Dia hanya bisa melaporkan fakta dari catatan yang memenuhi persyaratan.
• Inovasi berikutnya adalah pembaruan Free Space Map selama penerapan ruang hampa udara . Sayangnya, tidak ada pengembang sistem yang bekerja dengan PostgreSQL berpikir bahwa perlu untuk menghapus di akhir tabel, jika tidak lubang, ruang yang tidak terisi akan muncul. Untuk melacak ini, kami menerapkan FSM, yang memungkinkan kami untuk tidak memperbesar tabel, tetapi untuk memasukkan tuple ke dalam rongga. Sebelumnya, ini dilakukan dengan ruang hampa, tetapi pada akhirnya. Dan sekarang vakum mampu melakukan ini dalam proses, dan dalam sistem yang sarat muatan, ini membantu menjaga ukuran tabel tetap terkendali.
• Kemungkinan untuk melewati pemindaian indeks selama eksekusi vakum . Faktanya adalah bahwa semua indeks PostgreSQL, menurut teori database, disebut sekunder. Ini berarti bahwa indeks disimpan jauh dari tabel; petunjuk mengarah ke sana dari mereka. Pemindaian indeks saja memungkinkan Anda untuk tidak melakukan lompatan langsung ini, tetapi mengambil langsung dari indeks. Tetapi kekosongan, yang menghapus catatan, tidak dapat melihatnya dalam indeks dan memutuskan apakah akan menghapusnya atau tidak, hanya karena tidak ada data seperti itu dalam indeks. Karena itu, vakum selalu dilakukan dalam dua lintasan. Pertama, dia menelusuri tabel dan mencari tahu apa yang perlu dia hapus. Kemudian ia pergi ke indeks yang terlampir pada tabel ini, menghapus catatan yang merujuk pada yang ditemukan, kembali ke tabel dan menghapus apa yang akan terjadi. Dan tahap menuju ke indeks tidak selalu diperlukan.
  
  Jika sejak vakum terakhir tidak ada penghapusan atau pembaruan, maka Anda tidak memiliki catatan mati, Anda tidak perlu menghapusnya. Dalam hal ini, Anda tidak dapat masuk ke indeks. Ada seluk-beluk tambahan, b-tree tidak langsung menghapus halamannya, tetapi dalam dua lintasan. Karena itu, jika Anda menghapus banyak data dalam tabel, maka Anda perlu melakukan vakum. Tetapi jika Anda ingin membebaskan ruang dalam indeks, maka vakum dua kali.
  
  Seseorang akan terkejut, tabel apa ini yang tidak ada hapus atau perbarui? Bahkan, banyak yang berurusan dengan ini, hanya saja tidak berpikir. Ini adalah hanya tabel tambahan, di mana, misalnya, log ditambahkan. Di dalamnya, penghapusan sangat jarang. Dan ini sangat menghemat durasi vakum / autovacuum, mengurangi beban pada disk, penggunaan cache dan sebagainya.
• Bersamaan melakukan transaksi kompetitif . Ini bukan inovasi, tetapi peningkatan. Sekarang PostgreSQL mendeteksi bahwa ia akan melakukan sekarang, dan menunda komit dari transaksi saat ini, menunggu sisa komit. Harap dicatat bahwa fitur ini tidak banyak berpengaruh jika Anda memiliki server kecil dengan 2-4 core.
• postgres_fdw (Pembungkus Data Asing) . FDW adalah cara untuk menghubungkan sumber data eksternal sehingga terlihat seperti pasca-Kongres nyata. postgres_fdw memungkinkan Anda untuk menghubungkan tabel dari instance tetangga ke instance Anda, dan itu akan terlihat seperti yang asli. Sekarang salah satu batasan untuk memperbarui dan menghapus telah dihapus. PostgreSQL sering dapat menebak bahwa Anda perlu mengirim data mentah. Cara untuk mengeksekusi permintaan bergabung cukup sederhana: kita menjalankannya di mesin kita, kita menarik tabel dari instance menggunakan FDW, cari tahu kunci primer id yang perlu kita hapus, dan kemudian menerapkan pembaruan dan / atau menghapus, yaitu, data yang kita bolak-balik . Sekarang mungkin untuk dilakukan. Tentu saja, jika tabel berada pada mesin yang berbeda, ini tidak mudah, tetapi FDW memungkinkan Anda untuk membuat mesin jarak jauh melakukan operasi, dan kami hanya menunggu.
• toast_tuple_target . Ada situasi ketika data sedikit melampaui batas setelah itu perlu bersulang, tetapi pada saat yang sama bersulang dari nilai-nilai tersebut tidak selalu menyenangkan. Misalkan Anda memiliki batas 90 byte, dan Anda harus memasukkan 100. Anda harus mulai bersulang untuk 10 byte, tambahkan secara terpisah, maka ketika Anda memilih bidang ini Anda harus pergi ke indeks roti, mencari tahu di mana data yang diperlukan, pergi ke meja roti, kumpulkan dan beri.

Sekarang dengan bantuan fine-tuning Anda dapat mengubah perilaku ini untuk seluruh database atau tabel terpisah sehingga keluar kecil seperti itu tidak memerlukan penggunaan roti panggang. Tetapi Anda harus memahami apa yang Anda lakukan, tanpa ini, tidak ada yang akan berhasil.

WAL

• WAL (Tulis log depan) adalah log tulis depan. Ukuran segmen WAL sekarang diatur di initdb. Syukurlah, tidak saat menyusun.
• Logikanya juga telah berubah. Sebelumnya, himpunan segmen WAL diselamatkan dari saat pos pemeriksaan kedua dari belakang, dan sekarang dari yang terakhir. Ini secara signifikan dapat mengurangi jumlah data yang disimpan. Tetapi jika Anda memiliki database 1 TB, dan TPS = 1, yaitu, satu permintaan per detik, maka Anda tidak akan melihat perbedaannya.

Cadangkan dan replikasi

• Truncate muncul dalam replikasi logis . Itu adalah operasi DML terakhir yang tidak tercermin dalam replikasi logis. Sekarang tercermin.
• Pesan tentang persiapan muncul dalam replikasi logis . Sekarang Anda dapat menangkap persiapan transaksi, komitmen dua fase dalam replikasi logis. Ini diimplementasikan untuk pembangunan cluster - heterogen, homogen, sharded dan tidak berbayang, multimaster dan sebagainya.
• Pengecualian dari pg_basebackup tabel sementara dan tidak masuk log . Banyak yang mengeluh bahwa pg_basebackup menyertakan tabel yang tercantum. Dan tidak termasuk mereka, kami mengurangi ukuran cadangan. Tetapi asalkan Anda menggunakan tabel sementara dan tidak masuk log, jika tidak, opsi ini tidak akan berguna bagi Anda.
• Kontrol Checksumma dalam replikasi streaming (untuk tabel) . Ini memungkinkan Anda untuk memahami apa yang terjadi pada replika Anda. Sejauh ini, fungsi hanya diterapkan untuk tabel.
• Ada promosi posisi slot replikasi . Seperti biasa, Anda hanya bisa bergerak maju, mundur hanya jika ada WAL. Selain itu, Anda perlu memahami dengan baik apa yang Anda lakukan dengannya dan mengapa. Menurut pendapat saya, ini lebih merupakan opsi pengembangan, tetapi mereka yang menggunakan replikasi logis untuk beberapa aplikasi eksotis dapat menikmatinya.

Untuk dba

• Ubah tabel, tambahkan kolom, bukan nol standar X , tulis seluruh tabel. Ada sedikit biaya untuk ini: nilai default disimpan secara terpisah. Jika Anda mengambil tuple dan membutuhkan kolom ini, maka PostgreSQL terpaksa mengikuti jalur pengkodean tambahan untuk menarik nilai sementara, gantilah dalam tuple dan berikan kepada Anda. Namun demikian, seseorang dapat hidup dengannya.
• Vakum / analisis . Sebelumnya, Anda hanya bisa menerapkan kekosongan atau analisis ke seluruh database atau tabel tunggal. Sekarang dimungkinkan untuk melakukan ini ke beberapa tabel, dengan satu perintah.

Eksekusi paralel

• Konstruksi paralel indeks b-tree . Dalam versi 11, menjadi mungkin untuk menanamkan indeks b-tree di beberapa pekerja. Jika Anda memiliki mesin yang sangat bagus, banyak cakram dan banyak inti, maka Anda dapat membuat indeks secara paralel, ini menjanjikan peningkatan kinerja yang nyata.
• Hash koneksi paralel menggunakan tabel hash bersama untuk pelaksana . , -. , . - , . .
• , union, create table as, select create materialized view!
• - (limit) . .

:

alter table usr reset (parallel_workers)
create index on usr(lower((so).occ)) — 2
alter table usr set (parallel_workers=2)
create index on usr(upper((so).occ)) — 1.8

parallel worker. . 16 4 ( ) 2 ., — 1,8 . , , . , .

:

explain analyze
select u1.* from usr u, usr1 u1 where
u.id=u1.id+0

, . , user — , . . , , .

, PostgreSQL 11 .



1425 , 1,5 . 1,4 . 2 . , 9.6 : 1 — 1 ., 2 1 . , 10 tuple. 11 . : user, batch, x-scan append .

:



. 211 , 702 . , 510 1473. , 2 .

parallel hash join. . — 4. , .

parallel index scan . batch . ? hash join, . user . , parallel hash, .

1 . , OLAP-, OLTP . OLTP , .

.

• . , . , «» «», index scan, . (highly skewed data), , . . , , .
• «», .

Window-

SQL:2011, .

, , . , , , , , .

websearch, . , . , .

# select websearch_to_tsquery('dog or cat');
----------------------
'dor' | 'cat'
# select websearch_to_tsquery('dog -cat');
----------------------
'dor' & !'cat'
# select websearch_to_tsquery('or cat');
----------------------
'cat'

— dog or cat — . Websearch . | , . “or cat”. , . websearch “or” . , -, .

Websearch — . : , . , .

Json(b)

10- , 11- . json json(b), tsvector. ( json(b)) - . , , , bull, numeric, string, . .

# select jsonb_to_tsvector
('{"a":"texts", "b":12}', '"string"');
-------------------
'text':1
# select jsonb_to_tsvector
('{"a":"texts", "b":12}', '["string", "numeric"]');
-------------------
'12':3 'text':1

json(b), . , , , .

PL/*

.

CREATE PROCEDURE transaction_test1()
LANGUAGE plpgsql
AS $$
BEGIN
FOR i IN 0..9 LOOP
INSERT INTO test1 (a) VALUES (i);
IF i % 2 = 0 THEN
COMMIT;
ELSE
ROLLBACK;
END IF;
END LOOP;
END
$$;
CALL transaction_test1();

call, , . . . select, insert .

, , PostgreSQL . Perl, Python, TL PL/pgSQL. Perl sp begin, .

PL/pgSQL : , .

pgbench

pgbench ICSB bench — , , . if, , . case, - . --init-steps , , .

random-seed. zipfian- . / — , . - , , - , .

, , - .

PSQL

, PSQL, . exit quit.

• — copy, 2 ³² . copy : 2 ³² - . , 2 ³¹ 2 ³² copy . 64- , 2 ⁶⁴ .
• POSIX : NaN ⁰ = 1 1 ^NaN = 1.