== 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.