🥇ພວກເຮົາໃຊ້ຄຸນສົມບັດທັງຫມົດຂອງດັດສະນີໃນ PostgreSQL

ໃນໂລກ Postgres, ດັດຊະນີແມ່ນມີຄວາມຈໍາເປັນສໍາລັບການນໍາທາງທີ່ມີປະສິດທິພາບຂອງການເກັບຮັກສາຖານຂໍ້ມູນ (ເອີ້ນວ່າ "heap"). Postgres ບໍ່ສະຫນັບສະຫນູນການຈັດກຸ່ມສໍາລັບມັນ, ແລະສະຖາປັດຕະຍະກໍາ MVCC ເຮັດໃຫ້ທ່ານສິ້ນສຸດດ້ວຍ tuple ດຽວກັນຫຼາຍຮຸ່ນ. ດັ່ງນັ້ນ, ມັນເປັນສິ່ງສໍາຄັນຫຼາຍທີ່ຈະສາມາດສ້າງແລະຮັກສາດັດສະນີທີ່ມີປະສິດທິພາບເພື່ອສະຫນັບສະຫນູນຄໍາຮ້ອງສະຫມັກ.

ນີ້ແມ່ນຄໍາແນະນໍາບາງຢ່າງສໍາລັບການເພີ່ມປະສິດທິພາບແລະການປັບປຸງການນໍາໃຊ້ດັດສະນີ.

ຫມາຍເຫດ: ຄໍາຖາມທີ່ສະແດງຂ້າງລຸ່ມນີ້ເຮັດວຽກຢູ່ໃນ unmodified ຖານຂໍ້ມູນຕົວຢ່າງ pagila.

ການນໍາໃຊ້ດັດຊະນີການປົກຫຸ້ມຂອງ

ໃຫ້ເບິ່ງຄໍາຮ້ອງຂໍເພື່ອແຍກທີ່ຢູ່ອີເມວສໍາລັບຜູ້ໃຊ້ທີ່ບໍ່ມີການເຄື່ອນໄຫວ. ຕາຕະລາງ customer ມີຖັນ active, ແລະການສອບຖາມແມ່ນງ່າຍດາຍ:

pagila=# EXPLAIN SELECT email FROM customer WHERE active=0;
                        QUERY PLAN
-----------------------------------------------------------
 Seq Scan on customer  (cost=0.00..16.49 rows=15 width=32)
   Filter: (active = 0)
(2 rows)

ການສອບຖາມຮຽກຮ້ອງລໍາດັບການສະແກນຕາຕະລາງເຕັມ customer. ໃຫ້ສ້າງດັດສະນີໃນຖັນ active:

pagila=# CREATE INDEX idx_cust1 ON customer(active);
CREATE INDEX
pagila=# EXPLAIN SELECT email FROM customer WHERE active=0;
                                 QUERY PLAN
-----------------------------------------------------------------------------
 Index Scan using idx_cust1 on customer  (cost=0.28..12.29 rows=15 width=32)
   Index Cond: (active = 0)
(2 rows)

ມັນຊ່ວຍ, ການສະແກນຕໍ່ມາໄດ້ກາຍເປັນ "index scan". ນີ້ຫມາຍຄວາມວ່າ Postgres ຈະສະແກນດັດສະນີ "idx_cust1", ແລະຫຼັງຈາກນັ້ນສືບຕໍ່ຊອກຫາ heap ຕາຕະລາງເພື່ອອ່ານຄ່າຂອງຖັນອື່ນໆ (ໃນກໍລະນີນີ້, ຖັນ. email) ທີ່ການສອບຖາມຕ້ອງການ.

ການປົກຫຸ້ມຂອງດັດຊະນີແມ່ນໄດ້ນໍາສະເຫນີໃນ PostgreSQL 11. ພວກເຂົາເຈົ້າອະນຸຍາດໃຫ້ທ່ານປະກອບຫນຶ່ງຫຼືຫຼາຍຄໍລໍາເພີ່ມເຕີມໃນດັດຊະນີຕົວມັນເອງ - ມູນຄ່າຂອງພວກມັນຖືກເກັບໄວ້ໃນບ່ອນເກັບຂໍ້ມູນດັດສະນີ.

ຖ້າພວກເຮົາໃຊ້ປະໂຫຍດຈາກຄຸນສົມບັດນີ້ແລະເພີ່ມມູນຄ່າອີເມລ໌ພາຍໃນດັດສະນີ, ຫຼັງຈາກນັ້ນ Postgres ບໍ່ຈໍາເປັນຕ້ອງຄົ້ນຫາ heap ຕາຕະລາງສໍາລັບມູນຄ່າ. email. ມາເບິ່ງວ່າອັນນີ້ຈະເຮັດວຽກຫຼືບໍ່:

pagila=# CREATE INDEX idx_cust2 ON customer(active) INCLUDE (email);
CREATE INDEX
pagila=# EXPLAIN SELECT email FROM customer WHERE active=0;
                                    QUERY PLAN
----------------------------------------------------------------------------------
 Index Only Scan using idx_cust2 on customer  (cost=0.28..12.29 rows=15 width=32)
   Index Cond: (active = 0)
(2 rows)

«Index Only Scan' ບອກພວກເຮົາວ່າ query ໃນປັດຈຸບັນພຽງແຕ່ຕ້ອງການດັດສະນີ, ເຊິ່ງຊ່ວຍຫລີກລ່ຽງ disk I/O ທັງຫມົດເພື່ອອ່ານ heap ຕາຕະລາງ.

ດັດຊະນີການປົກຄຸມແມ່ນມີພຽງແຕ່ສໍາລັບ B-trees ເທົ່ານັ້ນ. ຢ່າງໃດກໍຕາມ, ໃນກໍລະນີນີ້, ຄວາມພະຍາຍາມບໍາລຸງຮັກສາຈະສູງຂຶ້ນ.

ການນໍາໃຊ້ດັດຊະນີບາງສ່ວນ

ດັດສະນີບາງສ່ວນພຽງແຕ່ດັດສະນີຍ່ອຍຂອງແຖວໃນຕາຕະລາງ. ນີ້ຊ່ວຍປະຢັດຂະຫນາດຂອງດັດສະນີແລະເຮັດໃຫ້ການສະແກນໄວຂຶ້ນ.

ໃຫ້ເວົ້າວ່າພວກເຮົາຕ້ອງການທີ່ຈະໄດ້ຮັບບັນຊີລາຍຊື່ຂອງທີ່ຢູ່ອີເມວຂອງລູກຄ້າຂອງພວກເຮົາໃນຄາລິຟໍເນຍ. ຄໍາຮ້ອງສະຫມັກຈະເປັນດັ່ງນີ້:

SELECT c.email FROM customer c
JOIN address a ON c.address_id = a.address_id
WHERE a.district = 'California';
which has a query plan that involves scanning both the tables that are joined:
pagila=# EXPLAIN SELECT c.email FROM customer c
pagila-# JOIN address a ON c.address_id = a.address_id
pagila-# WHERE a.district = 'California';
                              QUERY PLAN
----------------------------------------------------------------------
 Hash Join  (cost=15.65..32.22 rows=9 width=32)
   Hash Cond: (c.address_id = a.address_id)
   ->  Seq Scan on customer c  (cost=0.00..14.99 rows=599 width=34)
   ->  Hash  (cost=15.54..15.54 rows=9 width=4)
         ->  Seq Scan on address a  (cost=0.00..15.54 rows=9 width=4)
               Filter: (district = 'California'::text)
(6 rows)

ສິ່ງທີ່ດັດສະນີທໍາມະດາຈະໃຫ້ພວກເຮົາ:

pagila=# CREATE INDEX idx_address1 ON address(district);
CREATE INDEX
pagila=# EXPLAIN SELECT c.email FROM customer c
pagila-# JOIN address a ON c.address_id = a.address_id
pagila-# WHERE a.district = 'California';
                                      QUERY PLAN
---------------------------------------------------------------------------------------
 Hash Join  (cost=12.98..29.55 rows=9 width=32)
   Hash Cond: (c.address_id = a.address_id)
   ->  Seq Scan on customer c  (cost=0.00..14.99 rows=599 width=34)
   ->  Hash  (cost=12.87..12.87 rows=9 width=4)
         ->  Bitmap Heap Scan on address a  (cost=4.34..12.87 rows=9 width=4)
               Recheck Cond: (district = 'California'::text)
               ->  Bitmap Index Scan on idx_address1  (cost=0.00..4.34 rows=9 width=0)
                     Index Cond: (district = 'California'::text)
(8 rows)

Scan address ໄດ້ຖືກແທນທີ່ໂດຍການສະແກນດັດສະນີ idx_address1ແລະຫຼັງຈາກນັ້ນສະແກນ heap address.

ເນື່ອງຈາກວ່ານີ້ແມ່ນການສອບຖາມເລື້ອຍໆແລະຕ້ອງໄດ້ຮັບການເພີ່ມປະສິດທິພາບ, ພວກເຮົາສາມາດນໍາໃຊ້ດັດສະນີບາງສ່ວນ, ເຊິ່ງດັດສະນີພຽງແຕ່ແຖວທີ່ມີທີ່ຢູ່ຂອງເມືອງ. ‘California’:

pagila=# CREATE INDEX idx_address2 ON address(address_id) WHERE district='California';
CREATE INDEX
pagila=# EXPLAIN SELECT c.email FROM customer c
pagila-# JOIN address a ON c.address_id = a.address_id
pagila-# WHERE a.district = 'California';
                                           QUERY PLAN
------------------------------------------------------------------------------------------------
 Hash Join  (cost=12.38..28.96 rows=9 width=32)
   Hash Cond: (c.address_id = a.address_id)
   ->  Seq Scan on customer c  (cost=0.00..14.99 rows=599 width=34)
   ->  Hash  (cost=12.27..12.27 rows=9 width=4)
         ->  Index Only Scan using idx_address2 on address a  (cost=0.14..12.27 rows=9 width=4)
(5 rows)

ໃນປັດຈຸບັນການສອບຖາມພຽງແຕ່ອ່ານ idx_address2 ແລະບໍ່ແຕະຕາຕະລາງ address.

ການນໍາໃຊ້ດັດຊະນີຫຼາຍຄຸນຄ່າ

ບາງຖັນທີ່ຈະຖືກດັດສະນີອາດຈະບໍ່ມີປະເພດຂໍ້ມູນ scalar. ປະເພດຖັນເຊັ່ນ jsonb, arrays и tsvector ມີຄ່າປະສົມ ຫຼືຫຼາຍຄ່າ. ຖ້າທ່ານຕ້ອງການດັດສະນີຄໍລໍາດັ່ງກ່າວ, ປົກກະຕິແລ້ວທ່ານຕ້ອງຄົ້ນຫາມູນຄ່າສ່ວນບຸກຄົນທັງຫມົດໃນຄໍລໍາເຫຼົ່ານັ້ນ.

ໃຫ້ພະຍາຍາມຊອກຫາຫົວຂໍ້ຂອງຮູບເງົາທັງຫມົດທີ່ມີການຕັດຈາກການໃຊ້ເວລາທີ່ບໍ່ສໍາເລັດ. ຕາຕະລາງ film ມີຖັນຂໍ້ຄວາມທີ່ເອີ້ນວ່າ special_features. ຖ້າຮູບເງົາມີ "ຄຸນສົມບັດພິເສດ", ຫຼັງຈາກນັ້ນຄໍລໍາປະກອບດ້ວຍອົງປະກອບເປັນ array ຂໍ້ຄວາມ Behind The Scenes. ເພື່ອຊອກຫາຮູບເງົາດັ່ງກ່າວທັງຫມົດ, ພວກເຮົາຈໍາເປັນຕ້ອງເລືອກແຖວທັງຫມົດທີ່ມີ "Behind The Scenes" ໃນເວລາທີ່ ໃດໆ ຄ່າ array special_features:

SELECT title FROM film WHERE special_features @> '{"Behind The Scenes"}';

ຜູ້ປະກອບການຮັງ @> ກວດເບິ່ງວ່າດ້ານຂວາແມ່ນສ່ວນຍ່ອຍຂອງເບື້ອງຊ້າຍ.

ແຜນການຮ້ອງຂໍ:

pagila=# EXPLAIN SELECT title FROM film
pagila-# WHERE special_features @> '{"Behind The Scenes"}';
                           QUERY PLAN
-----------------------------------------------------------------
 Seq Scan on film  (cost=0.00..67.50 rows=5 width=15)
   Filter: (special_features @> '{"Behind The Scenes"}'::text[])
(2 rows)

ເຊິ່ງຮ້ອງຂໍການສະແກນ heap ເຕັມທີ່ມີຄ່າໃຊ້ຈ່າຍ 67.

ໃຫ້ເບິ່ງວ່າດັດຊະນີ B-tree ປົກກະຕິຊ່ວຍພວກເຮົາ:

pagila=# CREATE INDEX idx_film1 ON film(special_features);
CREATE INDEX
pagila=# EXPLAIN SELECT title FROM film
pagila-# WHERE special_features @> '{"Behind The Scenes"}';
                           QUERY PLAN
-----------------------------------------------------------------
 Seq Scan on film  (cost=0.00..67.50 rows=5 width=15)
   Filter: (special_features @> '{"Behind The Scenes"}'::text[])
(2 rows)

ດັດຊະນີບໍ່ໄດ້ຖືກພິຈາລະນາ. ດັດຊະນີ B-tree ບໍ່ຮູ້ເຖິງການມີຢູ່ຂອງອົງປະກອບແຕ່ລະອັນໃນຄ່າທີ່ຖືກດັດສະນີ.

ພວກເຮົາຕ້ອງການດັດຊະນີ GIN.

pagila=# CREATE INDEX idx_film2 ON film USING GIN(special_features);
CREATE INDEX
pagila=# EXPLAIN SELECT title FROM film
pagila-# WHERE special_features @> '{"Behind The Scenes"}';
                                QUERY PLAN
---------------------------------------------------------------------------
 Bitmap Heap Scan on film  (cost=8.04..23.58 rows=5 width=15)
   Recheck Cond: (special_features @> '{"Behind The Scenes"}'::text[])
   ->  Bitmap Index Scan on idx_film2  (cost=0.00..8.04 rows=5 width=0)
         Index Cond: (special_features @> '{"Behind The Scenes"}'::text[])
(4 rows)

ດັດຊະນີ GIN ສະຫນັບສະຫນູນການສ້າງແຜນທີ່ຄ່າດຽວຕໍ່ກັບມູນຄ່າປະສົມປະສານທີ່ຖືກດັດສະນີ, ເຮັດໃຫ້ຄ່າໃຊ້ຈ່າຍໃນແຜນການສອບຖາມແມ່ນຫຼາຍກ່ວາເຄິ່ງຫນຶ່ງ.

ການກໍາຈັດດັດສະນີຊ້ໍາກັນ

ດັດນີສະສົມຕາມເວລາ, ແລະບາງຄັ້ງດັດຊະນີໃຫມ່ອາດມີຄໍານິຍາມດຽວກັນກັບຫນຶ່ງທີ່ຜ່ານມາ. ທ່ານສາມາດນໍາໃຊ້ມຸມເບິ່ງລາຍການເພື່ອໃຫ້ໄດ້ຄໍານິຍາມ SQL ທີ່ມະນຸດສາມາດອ່ານໄດ້ຂອງດັດສະນີ. pg_indexes. ນອກນັ້ນທ່ານຍັງສາມາດຊອກຫາຄໍານິຍາມທີ່ຄ້າຍຄືກັນໄດ້ຢ່າງງ່າຍດາຍ:

 SELECT array_agg(indexname) AS indexes, replace(indexdef, indexname, '') AS defn
    FROM pg_indexes
GROUP BY defn
  HAVING count(*) > 1;
And here’s the result when run on the stock pagila database:
pagila=#   SELECT array_agg(indexname) AS indexes, replace(indexdef, indexname, '') AS defn
pagila-#     FROM pg_indexes
pagila-# GROUP BY defn
pagila-#   HAVING count(*) > 1;
                                indexes                                 |                                defn
------------------------------------------------------------------------+------------------------------------------------------------------
 {payment_p2017_01_customer_id_idx,idx_fk_payment_p2017_01_customer_id} | CREATE INDEX  ON public.payment_p2017_01 USING btree (customer_id
 {payment_p2017_02_customer_id_idx,idx_fk_payment_p2017_02_customer_id} | CREATE INDEX  ON public.payment_p2017_02 USING btree (customer_id
 {payment_p2017_03_customer_id_idx,idx_fk_payment_p2017_03_customer_id} | CREATE INDEX  ON public.payment_p2017_03 USING btree (customer_id
 {idx_fk_payment_p2017_04_customer_id,payment_p2017_04_customer_id_idx} | CREATE INDEX  ON public.payment_p2017_04 USING btree (customer_id
 {payment_p2017_05_customer_id_idx,idx_fk_payment_p2017_05_customer_id} | CREATE INDEX  ON public.payment_p2017_05 USING btree (customer_id
 {idx_fk_payment_p2017_06_customer_id,payment_p2017_06_customer_id_idx} | CREATE INDEX  ON public.payment_p2017_06 USING btree (customer_id
(6 rows)

ດັດຊະນີ Superset

ມັນສາມາດເກີດຂື້ນໄດ້ວ່າທ່ານສິ້ນສຸດດ້ວຍດັດສະນີຫຼາຍ, ຫນຶ່ງໃນນັ້ນດັດສະນີ superset ຂອງຖັນທີ່ດັດສະນີດັດສະນີອື່ນໆ. ອັນນີ້ອາດຈະຕ້ອງການ ຫຼືອາດຈະບໍ່ຢາກໄດ້ - ຊຸບເປີເຊດອາດຈະສົ່ງຜົນໃຫ້ມີການສະແກນແບບດັດສະນີເທົ່ານັ້ນ, ເຊິ່ງເປັນສິ່ງທີ່ດີ, ແຕ່ມັນອາດຈະໃຊ້ພື້ນທີ່ຫຼາຍເກີນໄປ, ຫຼືການສອບຖາມທີ່ superset ມີຈຸດປະສົງເພື່ອເພີ່ມປະສິດທິພາບຈະບໍ່ຖືກໃຊ້ອີກຕໍ່ໄປ.

ຖ້າທ່ານຕ້ອງການອັດຕະໂນມັດຄໍານິຍາມຂອງດັດສະນີດັ່ງກ່າວ, ທ່ານສາມາດເລີ່ມຕົ້ນດ້ວຍ pg_index ຈາກຕາຕະລາງ pg_catalog.

ດັດຊະນີທີ່ບໍ່ໄດ້ໃຊ້

ເນື່ອງຈາກແອັບພລິເຄຊັນທີ່ໃຊ້ຖານຂໍ້ມູນພັດທະນາ, ດັ່ງນັ້ນການສອບຖາມທີ່ພວກເຂົາໃຊ້. ດັດຊະນີທີ່ເພີ່ມໃສ່ກ່ອນໜ້ານີ້ອາດຈະບໍ່ຖືກໃຊ້ໂດຍການສອບຖາມໃດໆ. ແຕ່ລະຄັ້ງທີ່ດັດສະນີຖືກສະແກນ, ມັນຖືກຫມາຍໂດຍຜູ້ຈັດການສະຖິຕິ, ແລະໃນມຸມມອງຂອງລະບົບ pg_stat_user_indexes ທ່ານສາມາດເບິ່ງມູນຄ່າ idx_scan, ເຊິ່ງເປັນຕົວນັບສະສົມ. ການຕິດຕາມມູນຄ່ານີ້ໃນໄລຍະເວລາ (ເວົ້າເປັນເດືອນ) ຈະໃຫ້ຄວາມຄິດທີ່ດີຂອງດັດສະນີທີ່ບໍ່ໄດ້ຖືກນໍາໃຊ້ແລະອາດຈະຖືກຫຼຸດລົງ.

ນີ້ແມ່ນການສອບຖາມເພື່ອຮັບເອົາການສະແກນປັດຈຸບັນຂອງດັດຊະນີທັງໝົດໃນ schema ‘public’:

SELECT relname, indexrelname, idx_scan
FROM   pg_catalog.pg_stat_user_indexes
WHERE  schemaname = 'public';
with output like this:
pagila=# SELECT relname, indexrelname, idx_scan
pagila-# FROM   pg_catalog.pg_stat_user_indexes
pagila-# WHERE  schemaname = 'public'
pagila-# LIMIT  10;
    relname    |    indexrelname    | idx_scan
---------------+--------------------+----------
 customer      | customer_pkey      |    32093
 actor         | actor_pkey         |     5462
 address       | address_pkey       |      660
 category      | category_pkey      |     1000
 city          | city_pkey          |      609
 country       | country_pkey       |      604
 film_actor    | film_actor_pkey    |        0
 film_category | film_category_pkey |        0
 film          | film_pkey          |    11043
 inventory     | inventory_pkey     |    16048
(10 rows)

ການສ້າງດັດສະນີຄືນໃຫມ່ດ້ວຍການລັອກຫນ້ອຍລົງ

ດັດຊະນີມັກຈະຕ້ອງໄດ້ຮັບການສ້າງໃຫມ່, ຕົວຢ່າງເມື່ອພວກມັນກາຍເປັນທ້ອງອືດ, ແລະການສ້າງໃຫມ່ສາມາດເລັ່ງການສະແກນໄດ້. ນອກຈາກນັ້ນ, ດັດຊະນີສາມາດເສຍຫາຍໄດ້. ການປ່ຽນແປງຕົວກໍານົດການດັດສະນີອາດຈະຮຽກຮ້ອງໃຫ້ມີການກໍ່ສ້າງຄືນໃຫມ່.

ເປີດໃຊ້ການສ້າງດັດຊະນີຂະຫນານ

ໃນ PostgreSQL 11, ການສ້າງດັດຊະນີ B-Tree ແມ່ນພ້ອມກັນ. ເພື່ອເລັ່ງຂະບວນການສ້າງ, ພະນັກງານຂະຫນານຫຼາຍສາມາດນໍາໃຊ້ໄດ້. ຢ່າງໃດກໍ່ຕາມ, ໃຫ້ແນ່ໃຈວ່າຕົວເລືອກການຕັ້ງຄ່າເຫຼົ່ານີ້ຖືກຕັ້ງຢ່າງຖືກຕ້ອງ:

SET max_parallel_workers = 32;
SET max_parallel_maintenance_workers = 16;

ຄ່າເລີ່ມຕົ້ນແມ່ນນ້ອຍເກີນໄປ. ໂດຍຫລັກການແລ້ວ, ຕົວເລກເຫຼົ່ານີ້ຄວນຈະເພີ່ມຂຶ້ນພ້ອມກັບຈໍານວນຂອງແກນປະມວນຜົນ. ອ່ານເພີ່ມເຕີມໃນ ເອກະສານ.

ການສ້າງດັດຊະນີພື້ນຖານ

ທ່ານສາມາດສ້າງດັດສະນີໃນພື້ນຫລັງໂດຍໃຊ້ຕົວເລືອກ CONCURRENTLY ຄຳ ສັ່ງ CREATE INDEX:

pagila=# CREATE INDEX CONCURRENTLY idx_address1 ON address(district);
CREATE INDEX

ຂັ້ນຕອນການສ້າງດັດສະນີນີ້ແຕກຕ່າງຈາກແບບປົກກະຕິທີ່ມັນບໍ່ຈໍາເປັນຕ້ອງມີການລັອກຢູ່ໃນຕາຕະລາງ, ແລະດັ່ງນັ້ນຈຶ່ງບໍ່ຂັດຂວາງການເຮັດວຽກການຂຽນ. ໃນທາງກົງກັນຂ້າມ, ມັນໃຊ້ເວລາຫຼາຍແລະບໍລິໂພກຊັບພະຍາກອນຫຼາຍ.

Postgres ສະຫນອງຄວາມຍືດຫຍຸ່ນຫຼາຍສໍາລັບການສ້າງດັດສະນີແລະວິທີການແກ້ໄຂກໍລະນີພິເສດຕ່າງໆ, ເຊັ່ນດຽວກັນກັບວິທີການຈັດການຖານຂໍ້ມູນໃນກໍລະນີທີ່ຄໍາຮ້ອງສະຫມັກຂອງທ່ານເຕີບໃຫຍ່ຂຶ້ນ. ພວກເຮົາຫວັງວ່າຄໍາແນະນໍາເຫຼົ່ານີ້ຈະຊ່ວຍໃຫ້ທ່ານໄດ້ຮັບການສອບຖາມຂອງທ່ານໄວແລະຖານຂໍ້ມູນຂອງທ່ານພ້ອມທີ່ຈະຂະຫນາດ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com

ການນໍາໃຊ້ຄຸນສົມບັດທັງຫມົດຂອງດັດສະນີໃນ PostgreSQL

ການນໍາໃຊ້ດັດຊະນີການປົກຫຸ້ມຂອງ

ການນໍາໃຊ້ດັດຊະນີບາງສ່ວນ

ການນໍາໃຊ້ດັດຊະນີຫຼາຍຄຸນຄ່າ

ການກໍາຈັດດັດສະນີຊ້ໍາກັນ

ດັດຊະນີ Superset

ດັດຊະນີທີ່ບໍ່ໄດ້ໃຊ້

ການສ້າງດັດສະນີຄືນໃຫມ່ດ້ວຍການລັອກຫນ້ອຍລົງ

ເປີດໃຊ້ການສ້າງດັດຊະນີຂະຫນານ

ການສ້າງດັດຊະນີພື້ນຖານ

ເພີ່ມຄວາມຄິດເຫັນ Отменитьответ

ການນໍາໃຊ້ຄຸນສົມບັດທັງຫມົດຂອງດັດສະນີໃນ PostgreSQL

ການ​ນໍາ​ໃຊ້​ດັດ​ຊະ​ນີ​ການ​ປົກ​ຫຸ້ມ​ຂອງ​

ການ​ນໍາ​ໃຊ້​ດັດ​ຊະ​ນີ​ບາງ​ສ່ວນ​

ການ​ນໍາ​ໃຊ້​ດັດ​ຊະ​ນີ​ຫຼາຍ​ຄຸນ​ຄ່າ​

ການກໍາຈັດດັດສະນີຊ້ໍາກັນ

ດັດຊະນີ Superset

ດັດຊະນີທີ່ບໍ່ໄດ້ໃຊ້

ການສ້າງດັດສະນີຄືນໃຫມ່ດ້ວຍການລັອກຫນ້ອຍລົງ

ເປີດໃຊ້ການສ້າງດັດຊະນີຂະຫນານ

ການສ້າງດັດຊະນີພື້ນຖານ

ເພີ່ມຄວາມຄິດເຫັນ Отменитьответ

ການນໍາໃຊ້ດັດຊະນີການປົກຫຸ້ມຂອງ

ການນໍາໃຊ້ດັດຊະນີບາງສ່ວນ

ການນໍາໃຊ້ດັດຊະນີຫຼາຍຄຸນຄ່າ