Postgres Pro Standard DBMS dirancang untuk memberikan produk kami kepada pengguna lebih cepat daripada yang kami dapat melalui PostgreSQL. Fitur-fitur yang belum termasuk dalam PostgreSQL, tetapi berada di jalur yang solid di sana, kami sertakan dalam Postgres Pro Standard. Juga, Postgres Pro Standard mencakup beberapa ekstensi yang diminta oleh pelanggan kami, tetapi tidak tersedia dalam distribusi PostgreSQL standar.
Kadang-kadang ada pengecualian ketika dalam Postgres Pro Standard, atas permintaan pengguna dan untuk memuaskan mereka, fitur-fitur yang kurang sepele dimasukkan, yang di tempat yang baik hanya di Postgres Pro Enterprise. Secara khusus, ini adalah PTRACK, tentangnya di bawah ini.
Tidak semua, tetapi bagian yang adil dari ekstensi tambahan dan utilitas yang termasuk dalam Standar, dikembangkan oleh Postgres Professional. Semua tambalan Postgres Pro diciptakan dan diimplementasikan dengan upaya kami sendiri. Mari kita mulai dengan perbaikan yang membutuhkan intervensi dalam mesin basis data.
Postgres Pro Standard berbeda dari PostgreSQL pada dua tingkatan: himpunan ekstensi dan utilitas yang ada dalam perakitan, dan kernel itu sendiri. Beberapa tambalan bermanfaat telah diterapkan pada kernel yang mengoptimalkan kinerja (misalnya, detektor kunci non-pengereman) dan tambalan yang meningkatkan efisiensi utilitas dan ekstensi (misalnya, untuk membuat pg_probackup bekerja dengan kekuatan penuh, tambalan PTRACK 2.0 diterapkan). Perbedaan antara versi inti Standard dan PostgreSQL diminimalkan untuk kompatibilitas semaksimal mungkin. Katakanlah ekstensi pg_pathman adalah bagian dari Standard, tetapi dapat diunduh dari github, dibangun dan diinstal pada vanilla PostgreSQL, tidak akan ada masalah kompatibilitas.
Mari kita mulai dengan perubahan di kernel.
Memeriksa Versi ICU
Dalam PostgreSQL, secara default, mereka digunakan untuk membandingkan string dengan membandingkannya menggunakan pustaka standar C. Namun ada juga kemungkinan menggunakan pustaka
ICU yang dikembangkan oleh IBM untuk tujuan yang sama. Perpustakaan ini sangat berharga bagi kami terutama karena menyediakan penyortiran platform-independen. Itulah sebabnya, misalnya, digunakan dalam 1C, dan rakitan "untuk one-es" PostgreSQL telah lama bekerja dengan pustaka ini.
Selain itu, perbandingan string melalui ICU terkadang lebih cepat daripada melalui libc, dan jumlah karakter yang diketahui lebih besar. Secara umum, perpustakaan bermanfaat. Postgres Pro Standard telah bekerja dengannya sejak versi pertama (9.5). Di PostgreSQL, bekerja dengan ICU telah dimungkinkan sejak versi 10.
Perpustakaan bermanfaat, tetapi Anda perlu mengingat beberapa situasi darurat. Misalkan pengguna DBMS telah memutuskan untuk memutakhirkan OS. Bersama-sama dengan OS, perpustakaan ICU juga dapat ditingkatkan, dan urutan kata dalam penyortiran akan berubah. Setelah itu, segera semua indeks akan menjadi tidak dapat digunakan: pencarian indeks akan memberikan hasil yang salah. Dalam kasus seperti itu, pangkalan mengatakan bahwa versi ICU telah berubah dan berhenti.
Tapi ini adalah keputusan yang sangat sulit. Setelah diskusi dan survei pelanggan, diputuskan untuk melunakkan perilaku. Sekarang hanya versi COLLATION (aturan penyortiran) yang diperiksa. Jika versi COLLATION yang digunakan dalam database telah berubah, database mengeluarkan peringatan ketika DBMS dimulai, tetapi tidak berhenti. Ini juga mengingatkan pengguna pada awal setiap sesi.
Optimalisasi kunci, gabungan, dan GROUP BY
Mekanisme deteksi kebuntuan dapat menurunkan kinerja. Standar tidak bisa lagi: patch kernel memungkinkannya bekerja tanpa pengereman. Setelah perbaikan besar pada mekanisme verifikasi, masalah ini hanya muncul pada sejumlah besar inti dan koneksi.
Peningkatan estimasi jumlah hasil gabungan di hadapan indeks yang sesuai.
Sekarang Anda dapat menggunakan indeks yang sesuai untuk mengelompokkan dan mengurutkan bidang. Fitur ini pertama kali dimasukkan dalam Standar 11.1.1 dan Perusahaan 11.2.1. Standar 12 kami juga memiliki satu.
Fedor Sigaev, CTO dari Postgres Professional, telah menawarkan tambalan-tambalan yang bermanfaat ini kepada masyarakat, mereka sedang dipertimbangkan dan, mudah-mudahan, akan dimasukkan dalam versi PG 13.
Kami menggambarkan optimalisasi operasi GROUP BY dengan contoh: mereka jelas dan mudah direproduksi.
Inti dari tambalan ini adalah Postgres tidak mengoptimalkan urutan bidang yang terdaftar dalam GROUP BY. Dan waktu eksekusi tergantung pada urutan pengelompokan (dengan hasil permintaan yang sama). Ada detail dalam
diskusi di milis
peretas .
Jika nilai di kolom pertama yang diproses unik, maka tidak ada yang perlu dibandingkan. Jika Anda mulai dari kolom lain, maka Anda harus membandingkan.
Mendapatkan ke tes:
DROP TABLE IF EXISTS btg; SELECT i AS id, i/2 AS p, format('%60s', i%2) AS v INTO btg FROM generate_series(1, 1000000) i;
Dalam bidang teks v, 60 spasi dihasilkan, diikuti oleh angka 0 atau 1. Entri terlihat seperti ini:
SELECT * FROM btg ORDER BY id DESC LIMIT 3; id | p | v
VACUUM btg; ANALYSE btg; SET enable_hashagg=off; SET max_parallel_workers= 0; SET max_parallel_workers_per_gather = 0;
Kelompokkan hasilnya:
VACUUM btg; EXPLAIN ANALYZE SELECT count(*) FROM btg GROUP BY p, v;
Paket PostgreSQL:
QUERY PLAN
Sekarang dalam urutan terbalik: v, dan hanya kemudian p:
EXPLAIN ANALYZE SELECT count(*) FROM btg GROUP BY v, p; QUERY PLAN
Ternyata kebalikannya terasa lebih lambat. Ini karena bidang pertama
v dianalisis dengan sebaran nilai yang kecil. Anda harus melakukan banyak pemeriksaan pada bidang yang tersisa (di sini - bidang p).
Mari kita lihat bagaimana kueri yang sama akan bekerja dengan tambalan yang memilih urutan optimal untuk memproses kolom:
QUERY PLAN
Dan dalam urutan terbalik:
QUERY PLAN
Rencananya mengatakan bahwa di sana dan di sana urutan pemrosesan sama: Sortir Key: p, v. Dengan demikian, waktunya kira-kira sama. Sekarang bandingkan apa yang terjadi ketika indeks digunakan.
CREATE INDEX ON btg(p, v); SET enable_seqscan=off; SET enable_bitmapscan=off; VACUUM btg; EXPLAIN ANALYZE SELECT count(*) FROM btg GROUP BY v, p ;
Di PostgreSQL:
QUERY PLAN
Dan dalam urutan terbalik:
QUERY PLAN
Sekarang dalam Standar:
QUERY PLAN
Dan dalam urutan terbalik:
QUERY PLAN
Waktunya sama lagi, yang alami: pada kenyataannya, tindakannya sama.
Mengganti byte nol saat boot
Postgres Pro tidak menerima nol byte (0x00) dalam data, jadi dengan COPY FROM mereka harus diganti,
jika tidak akan ada kesalahan . Ini adalah masalah nyata yang ditemui pelanggan saat mengimpor data dari file CSV. Solusinya adalah mengganti byte nol dengan karakter ASCII yang diberikan. Itu harus berbeda dari karakter QUOTE dan DELIMITER yang digunakan ketika menjalankan COPY FROM; jika tidak, hasilnya mungkin tidak terduga. Secara default, nilai variabel nul_byte_replacement_on_import (string) '\ 0', yaitu, tidak ada penggantian yang dilakukan.
WaitLSN
LSN adalah
nomor urut dalam log , yaitu, penunjuk ke posisi dalam WAL (Log Sequence Number). Perintah WAITLSN sedang menunggu untuk memainkan LSN yang ditentukan. Jika aplikasi berfungsi dengan master dan replika, maka Anda perlu memastikan bahwa mereka sinkron dari waktu ke waktu. WAITLSN adalah mekanisme interproses di PostgrePro yang mengontrol sinkronisasi selama
replikasi sinkron . Secara default, waktu tunggu tidak terbatas. Anda dapat membatalkan menunggu dengan menekan Ctrl + C atau menghentikan server postgres. Anda juga dapat mengatur batas waktu dengan menambahkan petunjuk TIMEOUT, atau memeriksa status LSN target tanpa menunggu dengan menggunakan petunjuk NOWAIT.
Misalkan aplikasi melakukan tindakan tertentu, menerima nomor LSN dari DBMS pada master dan sekarang ingin memastikan bahwa tindakan pada replika akan disinkronkan dengan master, mis. aplikasi dapat memastikan bahwa apa yang direkam pada wizard telah tiba di replika dan siap dibaca. Secara default, ini biasanya tidak dijamin. WAITLSN memungkinkan Anda untuk mengontrol interaksi ini dan memilih mode tidur dari INFINITELY secara default, ke TIMEOUT dan NOWAIT.
Membaca ulang variabel dari recovery.conf sebelumnya
Pada sinyal SIGHUP, PostgreSQL membaca ulang postgresql.conf, tetapi tidak recovery.conf. Patch kernel yang relatif baru diperkenalkan dalam Standar dan Perusahaan 10.4.1. terpaksa membaca ulang dan recovery.conf. Tetapi di Postgres 12 tidak ada file recovery.conf sama sekali: semua variabel darinya ditransfer ke postgresql.conf. Meskipun demikian, meskipun seluruh file dibaca kembali, variabel dari recovery.conf tidak didefinisikan ulang oleh SIGHUP, tetapi diperlukan restart Postgres. Dalam Standar, ini tidak diperlukan: semuanya dibaca dan didefinisikan ulang.
Dukungan PTRACK
PTRACK 2.0 adalah mekanisme PTRACK yang dirancang ulang untuk versi Standar dan Perusahaan 11 dan sebelumnya. Pada level DBMS, ia bekerja berkat patch kernel, dan sekarang ekstensi ptrack telah ditambahkan ke
patch . PTRACK 2.0 melacak perubahan halaman data dan menyediakan antarmuka untuk mengambil informasi ini. Ini dapat digunakan baik untuk tujuan diagnostik, misalnya, untuk mendapatkan gagasan tentang seberapa kuat instance "bermutasi" relatif ke titik waktu tertentu, ditetapkan sebagai nomor urut dalam log (LSN), dan untuk membuat cadangan tambahan.
Bagian paling sulit dan "mahal" dari prosedur cadangan tambahan, sebagai aturan, adalah untuk mengisolasi bagian dari halaman yang diubah dari seluruh set halaman dalam sebuah cluster. Karena kenyataan bahwa server dapat melakukan tugas ini dan dengan cepat memberikan informasi tentang halaman yang diubah, waktu cadangan tambahan menggunakan PTRACK berkurang secara signifikan.
PTRACK 2.0 menggunakan tabel hash dari ukuran yang ditentukan dalam memori bersama, disinkronkan secara berkala dengan file ptrack.map.
Karena perubahan mendasar dari mekanisme operasi internal dan antarmuka pengguna yang tidak kompatibel dengan versi yang lebih lama, ekstensi ptrack hanya tersedia dalam versi ke-12 dari PostgresPro Standard and Enterprise, dan akan tersedia sebagai patch dan ekstensi pada PostgreSQL 12.
Mengedit perintah dalam psql untuk Windows
Dukungan lanjutan untuk mengedit perintah input di psql untuk Windows diimplementasikan menggunakan WinEditLine. Sekarang Anda dapat menampilkan karakter huruf yang berbeda secara bersamaan (khususnya, Cyrillic biasanya ditampilkan pada Windows non-Rusia).
Struktur Paket Terpadu
Struktur paket paket biner untuk semua distribusi Linux dipersatukan untuk menyederhanakan migrasi di antara mereka dan memungkinkan untuk menginstal beberapa produk berbasis PostgreSQL yang berbeda bersama-sama tanpa konflik. Ini dapat ditemukan di
Bab 16 dari Dokumentasi.
Sekarang tentang ekstensi:
dump_stat
Itu muncul sedini 9,5. Saat mentransfer atau memulihkan data, akumulasi statistik biasanya tidak ditransfer. Jika Anda memasang kembali dengan perintah ANALYZE, maka itu akan dieksekusi untuk seluruh cluster, dan bukan untuk database yang ditentukan. Ini mungkin memerlukan banyak waktu ekstra untuk database besar.
Ekstensi dump_stat
menyediakan fungsi yang memungkinkan Anda membongkar dan mengembalikan konten tabel pg_statistic. Saat melakukan pengunggahan / pemulihan data, Anda dapat menggunakan dump_stat untuk mentransfer statistik yang ada ke server baru, tanpa harus menjalankan perintah ANALYZE untuk seluruh kluster.
Fungsi dump_statistic membongkar isi katalog sistem pg_statistic. Ini menghasilkan INSERT untuk setiap tuple di pg_statistic, kecuali untuk yang berisi statistik tentang tabel dalam skema information_schema dan pg_catalog.
jsquery
Ingatlah bahwa
ini adalah ekstensi untuk bekerja dengan JSON (B), bukan JS. Ini menyediakan satu set fungsi untuk memproses tipe data ini. Ini adalah bahasa permintaan khusus untuk pencarian yang efisien, menggunakan indeks, di JSON (B). Dalam
artikel di hub, Anda dapat melihat beberapa contoh jsquery dan metode alternatif bekerja dengan JSON (B), misalnya JSONPath (keduanya pengembangan perusahaan kami).
online_analyze
Ekstensi ini
menyediakan serangkaian fungsi yang segera memperbarui statistik dalam tabel yang ditentukan setelah operasi INSERT, UPDATE, DELETE, atau SELECT INTO di dalamnya. Penulis ekstensi adalah Fedor Sigaev.
Untuk menggunakan modul online_analyze, Anda harus memuat pustaka bersama:
LOAD 'online_analyze';
Pembaruan statistik dapat disesuaikan. Misalnya, atur persentase ukuran tabel atau jumlah minimum (ambang) perubahan baris, setelah itu statistik akan segera dikumpulkan.
pg_pathman
Ekstensi pg_pathman di Postgres Professional dibuat lebih awal daripada di kernel PostgreSQL dan mengimplementasikan serangkaian fungsi yang cukup lengkap untuk membuat partisi. Oleh karena itu, banyak operasi dengan bagian dapat dilakukan dengan mekanisme satu dan lainnya. Dianjurkan untuk tidak mencampur bagian yang dibuat oleh partisi deklaratif dan pg_pathman.
Namun, banyak operasi pg_pathman masih lebih cepat dan beberapa fitur hilang di PostgreSQL. Misalnya, pembuatan otomatis (pemotongan) bagian. Di PostgreSQL, Anda perlu mengatur batas-batas setiap bagian. Jika kita mengisi data tentang yang tidak diketahui sebelumnya berapa banyak bagian yang dapat dan harus tersebar, maka lebih mudah untuk mengatur interval dan membiarkan perangkat lunak memotong bagian itu sendiri - sebanyak yang diperlukan. pg_pathman tahu caranya, PostgreSQL tidak. Tapi, dimulai dengan PG 11, ada bagian default (default), di mana Anda bisa membuang semua catatan yang tidak jatuh ke bagian dengan batas yang ditentukan.
Ada kesepakatan dasar dengan para pemimpin komunitas PostgreSQL bahwa di masa depan yang terbaik, sementara fitur unik pg_pathman akan jatuh ke cabang utama. Tetapi sampai saat itu, pg_pathman dapat membuat hidup lebih mudah untuk admin DB aplikasi dan pemrogram aplikasi.
Buat ekstensi:
CREATE EXTENSION pg_pathman;
pg_pathman memungkinkan Anda untuk memecah tabel besar menjadi beberapa bagian dan menyediakan API yang nyaman - serangkaian fungsi untuk membuat bagian dan bekerja dengannya. Misalnya, menggunakan fungsi
create_range_partitions(relation REGCLASS, expression TEXT, start_value ANYELEMENT, p_interval INTERVAL, p_count INTEGER DEFAULT NULL, partition_data BOOLEAN DEFAULT TRUE);
kita bisa bertanya
SELECT create_range_partitions('log', 'dt', NULL::date, '1 month'::interval);
setelah itu kami menambahkan bagian:
SELECT add_range_partition('log', NULL, '2017-01-01'::date, 'log_archive', 'ts0'); SELECT add_range_partition('log', '2017-01-01'::date, '2017-02-01'::date, 'log_1'); SELECT add_range_partition('log', '2017-02-01'::date, '2017-03-01'::date', log_2');
Log arsip akan dibuat di ruang tabel ts0, sisanya secara default. Tapi Anda tidak bisa menentukan bagian secara eksplisit, tetapi percaya operasi DBMS ini dengan mengatur interval dan membuat bagian dalam satu langkah:
SELECT create_range_partitions('log', 'dt', '2017-01-01'::date, '1 month'::interval);
Pada tabel sederhana, akan terlihat seperti ini:
CREATE TABLE pg_pathmania(id serial, val float); INSERT INTO pg_pathmania(val) SELECT random() * 1000 FROM generate_series(1, 1000); SELECT create_range_partitions('pg_pathmania', 'id', 0, 50); test_parti=# \d+ pg_pathmania Table "public.pg_pathmania" Column | Type | Collation | Nullable | Default | Storage | S tats target | Description
Di PostgreSQL, kita harus membuat setiap bagian dengan tim kita sendiri. Dalam kasus seperti itu, tentu saja, mereka menulis skrip yang menghasilkan kode DDL yang diperlukan secara otomatis. Anda tidak perlu menulis skrip di pg_pathman, semuanya sudah ada di sana. Tapi ini bukan yang paling menarik. Kami akan menyisipkan catatan yang tidak hanya didapat oleh id ke bagian mana pun yang ada, tetapi juga tidak jatuh ke bagian terdekat:
INSERT INTO pg_pathmania(id, val) VALUES (2000, 277.835794724524);
Sekali lagi, periksa isi tabel dengan \ d + pg_pathmania:
Child tables: pg_pathmania_1, pg_pathmania_10, ... pg_pathmania_39, pg_pathmania_4, pg_pathmania_40, pg_pathmania_41,
Inilah yang terjadi: pg_pathman melihat bahwa catatan dengan id = 2000 tidak jatuh ke bagian yang sudah dibuat, menghitung berapa banyak yang harus dibuat, mengetahui interval RANGE yang tabelnya dipartisi sebelumnya, dan menciptakan bagian di mana catatan baru jatuh, dan, tentu saja, semua bagian antara batas atas dari bagian lama dan batas bawah dari bagian baru. Ini sangat nyaman, dan dalam kasus-kasus di mana nilai-nilai bidang pemisahan data yang diperbarui diprediksi dengan buruk, ini merupakan keuntungan serius pg_pathman.
pg_query_state
Ekstensi yang kami kembangkan ini
memungkinkan kami
untuk mengetahui kondisi permintaan saat ini dalam proses penayangan. Itu sudah ada sejak versi 9.5 dan disebabkan oleh lahirnya banyak permintaan admin pelanggan.
Faktanya adalah bahwa EXPLAIN ANALYZE memungkinkan Anda untuk melihat statistik eksekusi yang dikumpulkan dari setiap node dari pohon paket, tetapi statistik ini dikumpulkan hanya setelah kueri diselesaikan. Namun dalam hidup, sayangnya, ada situasi ketika Anda perlu melihat apa yang permintaannya belum selesai dan mungkin tidak akan berakhir. pg_query_state memungkinkan Anda untuk melihat statistik saat ini dari query yang berjalan dalam proses servis eksternal. Dalam hal ini, format output yang dihasilkan hampir identik dengan output dari perintah EXPLAIN ANALYZE yang biasa.
Utilitas:
pgBuncer
Ini adalah penarik koneksi yang populer sehingga akan aneh untuk membicarakannya di sini. Hanya saja itu adalah bagian dari Standar, dan itu harus diinstal secara terpisah dalam kasus vanilla PostgreSQL.
pg_probackup
pg_probackup adalah salah satu perkembangan kami yang paling populer. Ini adalah manajer cadangan dan pemulihan yang sedang dikembangkan dan diperbarui terutama oleh Anastasia Lubennikova, Grigory Smolkin, dan komunitas pengguna.
Keunggulan kompetitif pg_probackup: cadangan inkremental dengan granularitas blok (8KB), tiga mode cadangan inkremental (PAGE, DELTA, PTRACK), pemeriksaan integritas cadangan atas permintaan, verifikasi cluster PostgreSQL, kompresi cadangan, pemulihan sebagian, dll.
Mode penyalinan tambahan PTRACK, mengandalkan
ekstensi dengan nama yang sama sebagai bagian dari mekanisme yang dirancang ulang - PTRACK 2.0 - telah menjadi lebih cepat dan sekarang jelas merupakan mode pg_probackup tercepat dan "termurah".
pg_repack
pg_repack adalah utilitas populer, operasinya mirip dengan VACUUM FULL atau
CLUSTER . Itu tidak hanya mengemas ulang tabel, menghapus void, tetapi juga tahu cara mengembalikan urutan fisik indeks berkerumun. Tidak seperti CLUSTER dan VACUUM FULL, ia melakukan operasi ini "saat bepergian", melakukan tanpa kunci tabel eksklusif dan umumnya bekerja secara efisien. Itu tidak termasuk dalam versi vanilla.
pg_variables
Tentang ekstensi ini di habr ada
artikel menarik
dari karyawan kami Ivan Frolkov. Alasan untuk perpanjangan adalah bahwa bekerja dengan hasil antara kadang-kadang tidak nyaman dan mahal. Artikel ini mengeksplorasi alternatif. Yang paling umum adalah tabel sementara.
Sebagai gudang data sementara, ekstensi pg_variables jauh lebih produktif daripada tabel sementara (tes pgbench ada dalam artikel), dan itu lebih nyaman: set data didefinisikan oleh pasangan "paket-variabel", yang dapat dilewatkan sebagai parameter, dikembalikan dari fungsi, dll. Ada fungsi set / get untuk bekerja dengan variabel. Jadi, misalnya, Anda dapat menyimpan banyak variabel (paket adalah nama paket, dan ekspresi setelah titik desimal adalah variabel dalam paket ini:
SELECT pgv_set_int('package','#'||n,n), n FROM generate_series(1,1000000) AS gs(n);
Variabel memiliki properti yang menarik: bukan bug atau keuntungan, tetapi fitur: data yang disimpan oleh ekstensi berarti ada di luar transaksi - mereka disimpan baik dalam hal memperbaiki transaksi dan dalam kasus rollback; Selain itu, bahkan ketika menjalankan perintah terpisah, sebagian data dapat diperoleh:
SELECT pgv_insert('package', 'errs', row(n)) FROM generate_series(1,5) AS gs(n) WHERE 1.0/(n-3)<>0; ERROR: there is a record in the variable "errs" with same key test_parti=# SELECT * FROM pgv_select('package','errs') AS r(i int); i
Di satu sisi, ini sangat tidak nyaman - dalam beberapa kasus perlu untuk menghapus data yang dimasukkan secara tidak benar, tetapi di sisi lain hal ini dapat menjadi sangat berguna - misalnya, menyimpan beberapa data bahkan jika terjadi kemunduran transaksi.
Dokumentasi memiliki detail.
Kesimpulannya, beberapa ekstensi lagi:
sr_plan, plantuner
sr_plan menyimpan dan mengembalikan paket kueri. Sertakan seperti ini:
SET sr_plan.write_mode = true;
Setelah itu, paket untuk semua kueri berikutnya akan disimpan dalam tabel sr_plans hingga variabel ini disetel ke false. Paket semua permintaan, termasuk yang berulang, disimpan.
plantuner mendukung petunjuk bagi scheduler untuk menghubungkan atau memutus indeks yang ditentukan saat menjalankan kueri. Hanya ada dua variabel GUC: enable_index / desable_index:
SET plantuner.disable_index='id_idx2';
Ekstensi untuk pencarian teks lengkap: shared_ispell, pg_tsparser
Ekstensi shared_ispell, yang memungkinkan Anda untuk menempatkan
kamus di memori bersama, adalah dalam Standar dan bukan di PostgreSQL. Kumpulan hunspell-dict kami memiliki kamus untuk bahasa:
- hunspell_en_us,
- hunspell_fr,
- hunspell_nl_nl,
- hunspell_ru_ru
Ekstensi pg_tsparser adalah
penganalisis pencarian teks
alternatif . Ekstensi ini mengubah strategi penguraian teks standar untuk kata-kata yang mencakup garis bawah, serta angka dan huruf yang dipisahkan oleh garis bawah. Selain setiap bagian dari kata yang dikembalikan secara default, pg_tsparser juga mengembalikan seluruh kata. Ini sangat penting untuk dokumentasi teknis atau artikel seperti ini, di mana kode program ditemukan, dan di dalamnya ada kata-kata seperti "pg_tsparser", "pg_probackup", "jsonb_build_object". Parser ini memahami kata-kata ini tidak hanya sebagai satu set komponen, tetapi juga sebagai token tunggal, dan dengan demikian meningkatkan kualitas pencarian.
Ekstensi untuk 1C
- mchar adalah tipe data opsional untuk kompatibilitas dengan Microsoft SQL Server;
- fulleq - menyediakan operator kesetaraan tambahan untuk kompatibilitas dengan Microsoft SQL Server;
- fasttrun - menyediakan fungsi transaksi-tidak aman untuk memotong tabel sementara, yang mencegah direktori pg_class dari tumbuh.
Ini menyimpulkan ulasan singkat ini, tetapi bukan perbedaan antara PostgresPro Standard dan PostgreSQL. Kami menyebutkan yang utama, tetapi Anda dapat membandingkan versi secara detail dengan memulai, misalnya, dari halaman ini .