Tugas 1

Database Performance Tuning Pada PostgreSQL

IF3140 Manajemen Basis Data

Ferdian Ifkarsyah - 13517024

Kevin Nathaniel Wijaya - 13517072
Muhammad Hanif Adzkiya - 13517120

PROGRAM STUDI TEKNIK INFORMATIKA

SEKOLAH TEKNIK ELEKTRO DAN INFORMATIKA
INSTITUT TEKNOLOGI BANDUNG
2019
A. Dasar Teori

a. Persiapan Postgres

Sebelum kita menggunakan database kita, kita perlu meng-​upload​ file

database sample kita(dvdrental.tar) ke dalam database. Caranya adalah sebagai berikut

1. Ingat lokasi folder “dvdrental.tar” yang kita download.

2. Buka terminal, dan ganti user kita ke “postgres” dengan perintah sebagai

berikut:

3. Masuk ke PSQL dengan perintah

4. Sebelumnya, buat database penampung dahulu dengan perintah:

5. Keluar lagi dengan perintah:

6. Masukkan database dvd rental dengan perintah:

7. Dan database siap digunakan. Masuk lagi ke psql, dan pilih database.
b. Query Processing

Pemrosesan Query dalam database dilakukan dalam 3 tahapan, yaitu:

1. Parsing, melakukan hal berikut:

a. Syntax Check: Memeriksa kesalahan dalam sintaks SQL seperti:

b. Semantic Check: Memeriksa apakah setiap objek yang ditulis terdapat

atau terdefinisi dalam database. Misalnya, kita ingin mengambil data

dari tabel “lawyer”, padahal tabel tersebut tidak ada dalam database.

c. Shared Pool Check

Setiap query yang pernah dieksekusi memiliki hash ​key.​ ​Value​ hash

tersebut adalah langkah-langkah optimisasi dan eksekusi. Jadi, jika

query yang akan dieksekusi ternyata sudah memiliki hash ​key,​ berarti

query ini pernah dieksekusi dan tidak perlu melakukan langkah

optimisasi dan eksekusi lagi.

2. Optimisasi

Dalam proses optimisasi, beberapa query plan dibangkitkan dan query

plan yang paling efisien disiapkan untuk dieksekusi. Query plan yang dipilih

ini juga disimpan sebagai ​value​ untuk langkah 1.c tadi.

 3. Eksekusi

Ini adalah proses eksekusi query hasil optimisasi dan pengembalian

hasilnya ke user.

c. Query Optimization

Query Optimization adalah langkah kedua dalam Query Processing. Ini adalah

proses pemilihan query plan yang paling efisien. Sebuah query SQL dapat memiliki

lebih dari 1 terjemahan relational algebra. DBMS akan memilih penyusunan relational

algebra ini yang membawa ke hasil yang lebih efisien.

Selain ditangani DBMS, kita sebagian user juga dapat melalui Query

Optimization di level query SQL. Beberapa cara umumnya adalah sebagai berikut:

1. Mendefinisikan field SELECT daripada menggunakan asterisk seperti

di SELECT *

Dengan mengenumerasi field-field yang kita butuhkan saja dan bukan

semuanya, kita dapat membuat ukuran tabel menjadi lebih kompak.

vs.

2. Menggunakan WHERE daripada HAVING.

Perbedaan penggunaan WHERE dan HAVING adalah jika WHERE

dieksekusi berbarengan saat tabel hasil terbentuk, HAVING baru

dieksekusi saat seluruh tabel ter-​join​ terlebih dahulu.

3. Jika memerlukan operator komparasi pada ​key​, libatkan “=”. Contoh:

 vs.

4. Sebisa mungkin, hindari menggunakan negasi(NOT, !=).

Menggunakan negasi akan membuat DBMS memeriksa semua baris

dalam tabel.

5. Mengurangi penggunaan subquery dalam operator IN.

vs.

6. Menggunakan UNION daripada OR untuk tabel berindeks.

vs.
d. Database Tuning

Selain​ Query Optimization​ untuk mempercepat hasil query, dapat dilakukan tuning

terhadap database. Performance tuning pada database dapat dilakukan dengan 3 level

yaitu: Perangkat Keras, Database System Parameter, dan Skema.

1. Perangkat Keras semisal menambahkan disk untuk mempercepat I/O,

menambah memori untuk meningkatkan ​buffer hits​, dan membeli CPU yang

lebih cepat.

2. Database System Parameter, misalnya mengatur ukuran buffer untuk

menghindari ​paging buffer.​

3. Level yang paling mudah dilakukan adalah dengan merubah desain dari

database. Perubahan desain dari database dapat dilakukan dengan cara-cara

termasuk tetapi tidak terbatas pada:

● Splitting tables: Terkadang membagi tabel dapat meningkatkan

performansi. Pembagian tabel dapat dilakukan dengan dua cara yaitu

secara horizontal dan vertikal

● Denormalization: Penurunan normalisasi skema database untuk

meningkatkan kecepatan query. Denormalisasi dapat dilakukan dengan

cara-cara berikut:
 ○ Adding redundant columns​: Penambahan kolom yang redundan atau

duplikasi dari kolom tabel lain untuk menghilangkan perlunya operasi

join dengan tabel lain untuk satu kolom.

○ Adding derived attributes:​ Menambahkan kolom agregasi yang

diperlukan pada sebuah tabel.

○ Collapsing tables​: Menggabungkan tabel menjadi satu sehingga

menghilangkan perlunya operasi join.

○ Duplicating tables:​ Menduplikasi tabel yang sering digunakan

● Meng-cluster ​disk page record​ yang sering digunakan secara bersamaan dalam

query ​join​. Hal ini dilakukan dengan cara menghitung join dengan optimal.
B. Deskripsi Persoalan

a. Skema Basis Data

b. Daftar Query

i. Query 1

ii. Query 2

iii. Query 3
C. Query Processing

a. Proses Eksekusi Query

i. Query 1

ii. Query 2
iii. Query 3

b. Waktu Eksekusi Query

Query Planning Time Execution Time

Query 1 1.112 ms 8.452 ms

Query 2 0.674 ms 7.825 ms

Query 3 0.728 ms 11.863 ms

c. Analisis perbandingan ketiga query

Dari ketiga query yang digunakan, query yang memberikan waktu eksekusi

tersedikit adalah Query 2 dengan 7.825ms(hijau), disusul Query 1 dengan

8.452ms(kuning), dan terakhir Query 3 dengan 11.863 ms(merah).

Query 1 men-​join ​actor dan ​film_actor terlebih dahulu. Lalu, men-​join-​ kannya

dengan ​film_category​. Mungkin, ini lah cara paling awal yang terpikirkan saat kita

ingin mendapatkan goal “Mencari jumlah aktor dan banyak kategori film berbeda

yang telah ia mainkan.”

 Dari query 1, kita tahu bahwa sebenarnya men-​join-​kan ​actor dan ​film_actor

terlebih dahulu akan menambah ​size tabel intermediate kita. Oleh karena itu, Query 2

men-​join ​film_actor dan ​film_category terlebih dahulu, lalu di GROUP BY dengan

actor_id.​

Dibanding Query 2, Query 3 menjadi lebih lama(bahkan paling lama) karena

tidak mengoptimisasi/mengurangi row ​film_actor dan ​film_category terlebih dahulu

dan ​me-materialize​-nya ketimbang langsung menyodorkan hasil untuk langkah

berikutnya.

d. Query yang lebih efisien

i. Query

SELECT​ a.actor_id,
a.first_name,
ac.num
FROM​ actor a
JOIN
( ​SELECT​ actor_id,
​COUNT​(​DISTINCT​ fc.category_id) ​AS​ num
​FROM​ film_actor fa
​JOIN​ film_category fc ​ON​ fa.film_id ​=​ fc.film_id
​GROUP BY​ actor_id ) ​AS​ ac ​ON​ a.actor_id ​=​ ac.actor_id
 ii. Mengapa lebih efisien?

Query ini adalah sedikit modifikasi dari Query 2 dengan membaca lebih awal

tabel ​actor.​ Meskipun, ini menambah cost 4.00 pada awal, namun ini mengurangi

cost 16.00 pada Query 2 walaupun pada Query 2 dilakukan dengan index. Hal ini

dilakukan karena penggunaan index dirasa kurang signifikan untuk tabel ​actor

yang hanya memiliki 200 rows.

D. Database Design Tuning

a. Permintaan Query

Query Hasil (172 msec):

SELECT​ customer.first_name,
customer.last_name,
hasil.peminjaman,
​CASE
 ​WHEN​ hasil.peminjaman ​<​ ​40​ ​THEN​ ​10
​WHEN​ hasil.peminjaman > ​ =​ ​40
​AND​ hasil.peminjaman ​<​ ​60​ ​THEN​ ​20
​ELSE​ ​30
​ ND​ ​AS​ diskon
E
FROM
( ​SELECT​ t.customer_id,
​count​(​*​) ​AS​ peminjaman
​FROM
( ​SELECT​ customer_id
​FROM​ public.rental
​UNION ALL​ ​SELECT​ customer_id
​FROM​ public.payment ) t
​GROUP BY​ t.customer_id
​ORDER BY​ t.customer_id ) hasil
JOIN​ public.customer ​ON​ public.customer.customer_id ​=
hasil.customer_id
ORDER BY​ hasil.customer_id;

b. DB Tuning untuk Query Tersebut

i. Derived Column

1. Menambahkan dua Derived Column pada tabel Customer yang menyimpan

jumlah peminjaman customer dan diskon.

2. Hal tersebut akan mengeliminasi proses union dan join dari query tersebut dan

hanya mengambil nilai dari tabel yang sama yaitu tabel Customer.

3. Query hasil (120 msec)

SELECT​ customer.first_name,
customer.last_name,
customer.peminjaman,
customer.diskon
FROM​ public.customer
ORDER BY​ public.customer.customer_id;

4. Skema hasil perubahan dan query untuk migrasi ke struktur basis data baru

a. Query Migrasi

ALTER​ ​TABLE​ public.Customer ADD COLUMN peminjaman

integer​ DEFAULT ​0​;
 UPDATE​ public.Customer
SET​ peminjaman ​=​ t.peminjaman
FROM
(​SELECT​ customer.customer_id,
hasil.peminjaman
​FROM
(​SELECT​ t.customer_id,
​count​(​*​) ​AS​ peminjaman
​FROM
(​SELECT​ customer_id
​FROM​ public.rental
​UNION ALL​ ​SELECT​ customer_id
​FROM​ public.payment) t
​GROUP BY​ t.customer_id
​ORDER BY​ t.customer_id) hasil
​JOIN​ public.customer ​ON
public.customer.customer_id ​=​ hasil.customer_id
​ORDER BY​ hasil.customer_id) t
WHERE​ t.customer_id ​=​ public.Customer.customer_id;
ALTER​ ​TABLE​ public.Customer ADD COLUMN diskon
integer​ DEFAULT ​10​;
UPDATE​ public.Customer
SET​ diskon ​=​ t.diskon
FROM
(​SELECT​ Customer.customer_id,
​CASE
​WHEN​ peminjaman ​<​ ​40​ ​THEN​ ​10
​WHEN​ peminjaman ​>=​ ​40
​AND​ peminjaman ​<​ ​60​ ​THEN​ ​20
​ELSE​ ​30
​END​ ​AS​ diskon
​FROM​ public.Customer
) t
WHERE​ t.customer_id ​=​ public.Customer.customer_id;

b. Skema hasil perubahan

customer = (​customer_id​, store_id, first_name, last_name, email,

address_id, activebool, create_date, last_update, active, peminjaman,

diskon)
ii. Table Splitting

1. Table splitting tabel customer menjadi customer_name = (​customer_id​,

first_name, last_name) dan customer_info = (​customer_id​, store_id, email,

address_id, activebool, create_date, last_update, active)

2. Hal tersebut dilakukan karena pencarian ​first name​ dan ​last name​ akan hanya

dilakukan pada tabel dengan 3 kolom, sehingga hasil join akan relatif lebih

kecil dan lebih cepat untuk dilakukan

3. Query Hasil (122 msec)

SELECT​ customer_name.first_name,
customer_name.last_name,
hasil.peminjaman,
​CASE
​WHEN​ hasil.peminjaman ​<​ ​40​ ​THEN​ ​10
​WHEN​ hasil.peminjaman ​>=​ ​40
​AND​ hasil.peminjaman ​<​ ​60​ ​THEN​ ​20
​ELSE​ ​30
​END​ ​AS​ diskon
FROM
(​SELECT​ t.customer_id,
​count​(​*​) ​AS​ peminjaman
​FROM
(​SELECT​ customer_id
​FROM​ public.rental
​UNION ALL​ ​SELECT​ customer_id
​FROM​ public.payment) t
​GROUP BY​ t.customer_id
​ORDER BY​ t.customer_id) hasil
JOIN​ public.customer_name ​ON
public.customer_name.customer_id ​=​ hasil.customer_id
ORDER BY​ hasil.customer_id;

4. Skema hasil perubahan dan query untuk migrasi ke struktur basis data baru

a. Query Migrasi

CREATE​ ​TABLE​ customer_info ​AS​ ​TABLE​ customer;

ALTER​ ​TABLE​ public.customer_info

DROP​ COLUMN first_name;
ALTER​ ​TABLE​ public.customer_info
DROP​ COLUMN last_name;

ALTER​ ​TABLE​ public.customer_info

ALTER COLUMN customer_id
SET​ ​NOT​ ​NULL​;

ALTER​ ​TABLE​ public.customer_info

ALTER COLUMN store_id
SET​ ​NOT​ ​NULL​;

ALTER​ ​TABLE​ public.customer_info

ALTER COLUMN address_id
SET​ ​NOT​ ​NULL​;

ALTER​ ​TABLE​ public.customer_info

ALTER COLUMN activebool
SET​ ​NOT​ ​NULL​;

ALTER​ ​TABLE​ public.customer_info

ALTER COLUMN create_date
SET​ ​NOT​ ​NULL​;

ALTER​ ​TABLE​ public.customer_info ADD ​CONSTRAINT

customer_pkey1 ​PRIMARY​ ​KEY​ (customer_id);

ALTER​ ​TABLE​ public.customer_info ADD ​CONSTRAINT

customer_address_id_fkey1
FOREIGN KEY​ (address_id) ​REFERENCES​ public.address
(address_id) MATCH ​SIMPLE​ ​ON
UPDATE​ CASCADE ​ON
DELETE​ RESTRICT;

CREATE​ ​TABLE​ customer_name ​AS​ ​TABLE​ customer;

ALTER​ ​TABLE​ public.customer_name

ALTER COLUMN customer_id
SET​ ​NOT​ ​NULL​;

ALTER​ ​TABLE​ public.customer_name

ALTER COLUMN first_name ​TYPE​ ​character​ varying (​45​)
COLLATE pg_catalog."​default​";

ALTER​ ​TABLE​ public.customer_name

ALTER COLUMN first_name
SET​ ​NOT​ ​NULL​;

ALTER​ ​TABLE​ public.customer_name

ALTER COLUMN last_name ​TYPE​ ​character​ varying (​45​)
COLLATE pg_catalog."​default​";

ALTER​ ​TABLE​ public.customer_name

ALTER COLUMN last_name
SET​ ​NOT​ ​NULL​;

ALTER​ ​TABLE​ public.customer_name ADD ​PRIMARY​ ​KEY

(customer_id);

ALTER​ ​TABLE​ public.customer_name

DROP​ COLUMN store_id;

ALTER​ ​TABLE​ public.customer_name

DROP​ COLUMN email;

ALTER​ ​TABLE​ public.customer_name

DROP​ COLUMN address_id;

ALTER​ ​TABLE​ public.customer_name

DROP​ COLUMN activebool;

ALTER​ ​TABLE​ public.customer_name

DROP​ COLUMN create_date;

ALTER​ ​TABLE​ public.customer_name

DROP​ COLUMN last_update;

ALTER​ ​TABLE​ public.customer_name

DROP​ COLUMN active;

ALTER​ ​TABLE​ public.customer_info ADD ​CONSTRAINT

customer_customer_id_fkey1
FOREIGN KEY​ (customer_id) ​REFERENCES
public.customer_name (customer_id) MATCH ​SIMPLE​ ​ON
UPDATE​ CASCADE ​ON
DELETE​ RESTRICT;

ALTER​ ​TABLE​ public.rental

DROP​ ​CONSTRAINT​ rental_customer_id_fkey;

ALTER​ ​TABLE​ public.rental ADD ​CONSTRAINT

rental_customer_id_fkey
FOREIGN KEY​ (customer_id) ​REFERENCES
public.customer_name (customer_id) MATCH ​SIMPLE​ ​ON
UPDATE​ CASCADE ​ON
DELETE​ RESTRICT;

ALTER​ ​TABLE​ public.payment

DROP​ ​CONSTRAINT​ payment_customer_id_fkey;
 ALTER​ ​TABLE​ public.payment ADD ​CONSTRAINT
payment_customer_id_fkey
FOREIGN KEY​ (customer_id) ​REFERENCES
public.customer_name (customer_id) MATCH ​SIMPLE​ ​ON
UPDATE​ CASCADE ​ON
DELETE​ RESTRICT;

DROP​ ​TABLE​ public.customer CASCADE;

b. Skema hasil perubahan:

customer_name = (​customer_id​, first_name, last_name)

customer_info = (​customer_id​, store_id, email, address_id, activebool,

create_date, last_update, active)

FK (customer_info.customer_id -> customer_name.customer_id)

FK (rental.customer_id -> customer_name.customer_id)

FK (payment.customer_id -> customer_name.customer_id)

FK (customer_info.address_id -> address.address_id)

iii. Materialized View

1. Menambahkan materialized view yang berisi customer_id, first_name,

last_name, peminjaman, dan diskon. Peminjaman dihitung dari banyaknya

row di rental dan payment dengan customer_id yang sama, dan diskon

ditentukan berdasarkan peminjaman.

2. Hal tersebut dilakukan untuk adanya join dengan tabel customer, union antara

rental dan payment, karena semua data terdapat pada 1 materialized view.

3. Query Hasil (127 msec)

SELECT​ daftar_peminjaman.first_name,
daftar_peminjaman.last_name,
daftar_peminjaman.peminjaman,
daftar_peminjaman.diskon
 FROM​ public.daftar_peminjaman
ORDER BY​ public.daftar_peminjaman.customer_id;

4. Skema hasil perubahan dan query untuk migrasi ke struktur basis data baru

a. Query Migrasi

CREATE​ MATERIALIZED VIEW public.daftar_peminjaman

AS
SELECT​ customer.customer_id,
customer.first_name,
customer.last_name,
hasil.peminjaman,
​CASE
​WHEN​ hasil.peminjaman ​<​ ​40​ ​THEN​ ​10
​WHEN​ hasil.peminjaman ​>=​ ​40
​AND​ hasil.peminjaman ​<​ ​60​ ​THEN​ ​20
​ELSE​ ​30
​END​ ​AS​ diskon
FROM
(​SELECT​ t.customer_id,
​count​(​*​) ​AS​ peminjaman
​FROM
(​SELECT​ customer_id
​FROM​ public.rental
​UNION ALL​ ​SELECT​ customer_id
​FROM​ public.payment) t
​GROUP BY​ t.customer_id
​ORDER BY​ t.customer_id) hasil
JOIN​ public.customer ​ON​ public.customer.customer_id
=​ hasil.customer_id
ORDER BY​ hasil.customer_id ​WITH​ ​DATA​;

b. Skema hasil perubahan

View daftar_peminjaman = (customer_id, first_name, last_name,

peminjaman, diskon)
E. Observasi Perubahan Query Plan

a. Permintaan Query

b. Tiga Alternatif Query

i. Query 1

SELECT​ film.title ​AS​ judul,

​language​.​name​ ​AS​ bahasa,
category.name ​AS​ category,
film_act.jumlah_actor ​AS​ jumlah_actor,
rental.rental_date ​AS​ tgl_peminjaman,
rental.return_date ​AS​ tgl_pengembalian
FROM​ film
JOIN​ inventory ​ON​ film.film_id ​=​ inventory.film_id
JOIN​ rental ​ON​ inventory.inventory_id ​=
rental.inventory_id
JOIN​ ​LANGUAGE​ ​ON​ film.language_id ​=​ ​LANGUAGE​.language_id
JOIN​ film_category ​ON​ film.film_id ​=
film_category.film_id
JOIN​ category ​ON​ category.category_id ​=
film_category.category_id
JOIN
(​SELECT​ film.film_id,
​count​(​*​) ​AS​ jumlah_actor
​FROM​ film
​JOIN​ film_actor ​ON​ film.film_id ​=​ film_actor.film_id
​GROUP BY​ film.film_id ) ​AS​ film_act ​ON​ film.film_id ​=
film_act.film_id;

ii. Query 2

SELECT​ film.title ​AS​ judul,

​language​.​name​ ​AS​ bahasa,
category.name ​AS​ category,
film_act.jumlah_actor ​AS​ jumlah_actor,
rental.rental_date ​AS​ tgl_peminjaman,
rental.return_date ​AS​ tgl_pengembalian
FROM​ film
 JOIN​ inventory ​ON​ film.film_id ​=​ inventory.film_id
JOIN​ rental ​ON​ inventory.inventory_id ​=
rental.inventory_id
JOIN​ ​LANGUAGE​ ​ON​ film.language_id ​=​ ​LANGUAGE​.language_id
JOIN​ film_category ​ON​ film.film_id ​=
film_category.film_id
JOIN​ category ​ON​ category.category_id ​=
film_category.category_id
JOIN
(​SELECT​ film.film_id,
​count​(​*​) ​AS​ jumlah_actor
​FROM​ film
​JOIN​ film_actor ​ON​ film.film_id ​=​ film_actor.film_id
​GROUP BY​ film.film_id ) ​AS​ film_act ​ON​ film.film_id ​=
film_act.film_id;

iii. Query 3

WITH​ X ​AS
(​SELECT​ film.film_id ​AS​ film_id,
​COUNT​(​*​) ​AS​ jumlah_actor
​FROM​ film
​JOIN​ film_actor ​ON​ film.film_id ​=​ film_actor.film_id
​GROUP BY​ film.film_id )
SELECT​ film.title ​AS​ judul,
​language​.​name​ ​AS​ bahasa,
category.name ​AS​ category,
X.jumlah_actor ​AS​ jumlah_actor,
rental.rental_date ​AS​ tgl_peminjaman,
rental.return_date ​AS​ tgl_pengembalian
FROM​ film
JOIN​ ​LANGUAGE​ ​ON​ film.language_id ​=​ ​LANGUAGE​.language_id
JOIN​ film_category ​ON​ film.film_id ​=
film_category.film_id
JOIN​ category ​ON​ category.category_id ​=
film_category.category_id
JOIN​ X ​ON​ X.film_id ​=​ film.film_id
JOIN​ inventory ​ON​ inventory.film_id ​=​ film.film_id
JOIN​ rental ​ON​ inventory.inventory_id ​=
rental.inventory_id;
c. Kasus yang Membuat Query Plan Berubah

Query plan berubah karena statistik pada data berubah. Salah satu cara untuk

merubah statistik data adalah dengan menghapus beberapa data dari tabel.

d. Proses untuk Merubah Query Plan

Dalam merubah Query Plan, hal yang perlu dilakukan adalah :

1. Mengetahui Statistik Data

Tabel yang dibutuhkan untuk menjalankan query pada subbab E.A. adalah

tabel category, language, film, film_category, film_actor, inventory, dan

rental. Dari statistik pada database dvdrental, kita dapat mengetahui jumlah

baris pada masing - masing tabel yaitu :

Tabel Jumlah Baris

Category 16

Language 6

Film 1000

Film_Category 1000

Film_Actor 5462

Inventory 4581

Rental 16044

2. Menentukan Tabel yang signifikan dalam memengaruhi Query Plan

Dari tabel pada poin 1, tabel yang memiliki baris paling banyak adalah

tabel rental dan film_actor sehingga memungkinka terjadinya query jika kita

merubah data pada kedua tabel tersebut.

3. Menentukan Aksi yang diterapkan pada database untuk merubah Query Plan
 Aksi yang kami pilih adalah mengurangi data pada tabel rental secara

signifikan. Hal yang dilakukan adalah menjalankan query DELETE FROM

rental WHERE rental_id > 1000. Query tersebut akan menghapus semua baris

pada tabel rental yang memiliki rental_id > 1000 sehingga tabel rental hanya

berisi 1000 baris saja.

Catatan : Tentu saja, proses penghapusan baris pada tabel rental gagal

dikarenakan terdapat foreign key pada tabel payment. Oleh karena itu,

sebelumnya dieksekusi penghapusan data pada tabel payment yang memiliki

rental_id > 1000.

e. Perubahan eksekusi query yang terjadi dari hasil Explain Query

Perubahan pada Query A

Query plan sebelum perubahan :

Total time : 332 msec

Query plan setelah perubahan :

Total time : 104 msec

Perubahan pada Query B :

Query Plan sebelum perubahan :

Total time : 131 msec

Query Plan setelah perubahan :

Total time : 120 msec

Perubahan pada Query C :

Query Plan sebelum perubahan :

Total time : 142 msec

Query Plan setelah perubahan :

Query time : 83 msec

f. Analisis mengapa hal tersebut dapat terjadi.

Berdasarkan query plan sebelum dan sesudah perubahan data kita dapat

memperhatikan hal sebagai berikut :

● Sebelum perubahan data, query plan mengeksekusi join pada tabel film,

film_category, dan language. Setelah itu film akan dijoin dengan film_actor dan

query akan dijoin dengan hasil join antara inventory dan rental.

● Sebelum perubahan data, query plan mengeksekusi join pada tabel inventory dan

rental, hasil join tersebut akan dijoin dengan film, film_category, language, dan

category. Di akhir proses, query akan dijoin dengan film_actor.

● Berdasarkan hal tersebut, ​query plan merubah urutan ​join dikarenakan adanya

perubahan baris yang signifikan pada tabel rental. Jumlah baris pada tabel

menentukan preferensi database untuk menentukan urutan join. Secara garis besar,
 database akan melakukan join pada tabel yang berukuran lebih kecil terlebih

dahulu.

● Pada analisis ini, kami membagi join pada query plan menjadi 3 bagian join.

Bagian pertama, join antara film, category, dan language. Bagian kedua, film dan

film_actor. Bagian ketiga, inventory dan rental.

● Sebelum perubahan data, urutan yang dijalankan adalah join bagian pertama,

bagian kedua, dan terakhir adalah bagian ketiga. Hal ini dikarenakan tabel pada

join bagian pertama mempunya jumlah yang hampir sama yaitu 1000. Tabel pada

bagian join yang kedua memiliki jumlah dengan perbedaan antara tabel film dan

film_actor yang cukup besar. Jumlah baris pada film adalah 1000 dan jumlah baris

pada film_actor adalah 5462.Tabel pada bagian join ketiga memiliki jumlah baris

yang paling besar yaitu tabel inventory sebesar 4581 baris dan rental 16044 baris.

Untuk oprimasi, database menganggap join dengan ukuran yang lebih kecil

dahulu akan mempercepat query sehingga urutan join akan memprioritaskan join

pada tabel yang memiliki ukuran yang lebih kecil.

● Sebelum perubahan data, urutan yang dijalankan adalah join bagian ketiga, bagian

pertama, dan terakhir adalah bagian kedua. Dikarenakan tabel rental telah

mengalami penurunan baris yang besar, join bagian ketiga akan dieksekusi

terlebih dahulu. Hal ini karena terjadi penurunan jumlah baris hasil join

dibandingkan dengan jumlah baris pada inventory, yaitu 4581 menjadi 1000 baris.

Eksekusi kedua yang dilakukan adalah join bagian pertama karena memiliki

jumlah baris yang paling sedikit. Eksekusi terakhir yang dilakukan adalah bagian

kedua karena jumlah baris pada film_actor adalah paling banyak dengan jumlah

5462.
 Berdasarkan analisa tersebut, query plan dapat berubah setelah perubahan data

dilakukan pada tabel.

F. Kesimpulan dan Saran

a. Kesimpulan

Berdasarkan eksplorasi yang dilakukan terhadap PostgreSQL, kami mengambil

kesimpulan sebagai berikut :

● Indeks akan berpengaruh signifikan untuk query dengan tabel ​size​ yang cukup

besar. Namun, hanya akan memperlambat pada tabel yang kecil dan perubahan

data tabel.

● Database management system akan memilih query plan yang optimal berdasarkan

dari statistik tabel yang ada.

● Untuk mengoptimalkan query plan, perlu diketahui statistik data dari database

yang ada.

● Query yang berbeda akan mempengaruhi cost eksekusi query bergantung pada

operasi-operasi yang dilakukan seperti join.

● Design Tuning pada database akan mempengaruhi cost eksekusi query karena

berkurangnya jumlah operasi yang dilakukan.

b. Saran

Berdasarkan eksplorasi yang dilakukan terhadap PostgreSQL, kami mempunyai saran

sebagai berikut :

● Untuk melihat secara lebih akurat dan lebih jelas apakah sebuah query lebih

efektif dari query yang lainnya, diperlukan tabel dengan ukuran yang lebih besar.
 ● Kedepannya, dapat ditingkatkan lagi performansi query pada DBMS PostgreSQL

dengan mempertimbangkan urutan join, penggunaan query seperti WITH klausa,

dan memperhatikan statistik dari database yang tersedia.

● Pembuatan tabel dan view dapat dilakukan berdasarkan heuristik dan frekuensi

query yang dijalankan, sehingga operasi join dapat diminimalkan.

G. Pembagian Kerja

NIM Nama Apa yang dikerjakan Persentase

kontribusi

13517024 Ferdian Ifkarsyah Subbab A, C, Kesimpulan 33.3%

13517072 Kevin Nathaniel Subbab D, Kesimpulan 33.3%

Wijaya

13517120 Muhammad Hanif Subbab C.A, Subbab E, 33.3%

Adzkiya Kesimpulan

H. Referensi

[1] A. Silberschatz, H. F. Korth and S. Sudarshan, Database System Concepts, Singapura:

McGraw Hill, 2011.

[2] https://www.geeksforgeeks.org/sql-query-processing/