| 75 | | '''5.''' Иницијално беше разгледано индексирање преку `idx_cvc_client_id`, меѓутоа мерењата покажаа дека тој индекс го влошува времето на извршување (399ms → 4s 421ms) поради ниска селективност — колоната client_id враќа многу редови по вредност, па планерот прибегнува кон scatter reads наместо секвенцијален скен. Поради тоа, индексот беше отстранет. Перформансите на овој поглед се подобрени само преку индексите `idx_project_contract_id` и `idx_cvc_vendor_id` креирани во View1. Времето изминато во извршување на query-то изнесува: |
| | 74 | '''5.''' Иницијално беше разгледано индексирање преку `idx_cvc_client_id`, меѓутоа мерењата покажаа дека тој индекс го влошува времето на извршување (399ms → 4s 421ms) поради ниска селективност — колоната client_id враќа многу редови по вредност, па планерот прибегнува кон scatter reads наместо секвенцијален скен. Поради тоа, индексот беше отстранет. |
| | 75 | |
| | 76 | Иако индексите `idx_project_contract_id` и `idx_cvc_vendor_id` од View1 се присутни, планот за извршување останува непроменет — табелата `Client_Vendor_Contract` сеуште се скенира секвенцијално со ист cost од 7k, бидејќи овие индекси не се применливи за филтрирање по client_id. Разликата во времето на извршување од ~100ms е во рамките на нормална варијација и не може да се припише на индексирањето. Се заклучува дека овој поглед не може да се оптимизира преку индексирање. |
