wiki:QueryOptimization

Version 3 (modified by 231116, 2 weeks ago) ( diff )

--

1. Анализа на view vw_booking_details

Доколку сакаме да ги прикажеме сите комплетирани резервации со детали за гостин, хост, соба и локација, извршуваме:

SELECT *
FROM vw_booking_details
LIMIT 100;

Време потребно за пребарување:

~18 sec

Најбавна операција е sequential scan на bookings табелата со филтер:

booking_status = 'COMPLETED'

Со цел да се избегне sequential scan, додадовме partial index:

CREATE INDEX CONCURRENTLY idx_bookings_completed
ON bookings (guest_id, room_id)
WHERE booking_status = 'COMPLETED';

Време на извршување по додавање на индекс:

~18 sec -> ~11-12 sec

Со индексот добивме значително подобрување бидејќи PostgreSQL користи index scan наместо целосно пребарување на bookings.

2. Анализа на view vw_guest_activity

Доколку сакаме да ги прикажеме најактивните гости според број на комплетирани резервации, извршуваме:

SELECT *
FROM vw_guest_activity
WHERE completed_bookings > 3;

Време потребно за пребарување:

~276 sec

Главниот проблем е огромен број на GROUP BY, DISTINCT и сортирања врз милиони редови.

Нема дополнителен индекс што значително би ги подобрил перформансите на овој view.

3. Анализа на view vw_revenue_by_property

Доколку сакаме да ја анализираме заработката по сместување, извршуваме:

SELECT *
FROM vw_revenue_by_property
WHERE total_revenue > 10000;

Време потребно за пребарување:

~93 sec

Најголем проблем претставуваат:

  • massive sorting
  • group aggregate операции
  • join со payments и bookings

Нема дополнителен индекс што значително би помогнал, бидејќи PostgreSQL сепак мора да процесира милиони редови за агрегација.

4. Анализа на view vw_room_details

Доколку сакаме да прикажеме детали за собите, нивната достапност и резервации, извршуваме:

SELECT *
FROM vw_room_details
WHERE status = 'ACTIVE';

Време потребно за пребарување:

~274 sec

Главниот bottleneck е:

  • massive joins
  • огромен број редови од availability_blocks
  • aggregate операции

Нема дополнителен индекс што значително би помогнал.

5. Анализа на view vw_review_summary

Доколку сакаме да ги прикажеме најдобро оценетите сместувања, извршуваме:

SELECT *
FROM vw_review_summary
WHERE rating >= 4;

Време потребно за пребарување:

~2.3 sec

Додадовме индекс:

CREATE INDEX CONCURRENTLY idx_reviews_booking_id
ON reviews (booking_id);

Време на извршување по додавање на индекс:

~2.3 sec -> ~2.0 sec

Со индексот добивме мало подобрување бидејќи PostgreSQL побрзо ги извршува join операциите помеѓу reviews и bookings.

6. Анализа на availability query

Доколку сакаме да ги прикажеме сите идни availability windows за активни соби, извршуваме:

SELECT *
FROM availability_windows aw
JOIN rooms r ON aw.room_id = r.room_id
WHERE aw.available_date >= CURRENT_DATE
AND r.status = 'ACTIVE';

Време потребно за пребарување:

~17 sec

Главниот проблем е sequential scan на availability_windows.

Додадовме индекс:

CREATE INDEX CONCURRENTLY idx_availability_windows_date_room
ON availability_windows (available_date, room_id);

Време на извршување по додавање на индекс:

~17 sec -> ~8-9 sec

Со индексот добивме значително подобрување бидејќи PostgreSQL избегнува целосно sequential scan на availability_windows.

Attachments (21)

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.