Pomôže rozšírenie WHERE

[Stanislav Hruška]

Mám FKFOCS, FKSERPAR - cudzie kľúče a YEARS
FKSERPAR je unikátne pre každú dvojicu FKFOCS a YEARS
Prvý prípad. Tak to mám teraz

Kód: [Vybrat]

WHERE FKSERPAR = :FKSERPAR Ak podmienku rozšírim, bude vykonanie dopytu rýchlejšie?

Kód: [Vybrat]

WHERE FKFOCS = :FKFOCS AND YEARS = :YEARS AND FKSERPAR = :FKSERPAR

[vandrovnik]

Nebude nejjednodušší to prostě vyzkoušet?

[Stanislav Hruška]

Teraz mám veľmi malý počet v záznamov. Takže žiaden rozdiel nezistím.
Dúfal som, že niekto s tým má všeobecnú skúsenosť.

[pf1957]

Teraz mám veľmi malý počet v záznamov. Takže žiaden rozdiel nezistím.
Dúfal som, že niekto s tým má všeobecnú skúsenosť.

Uz jsem ti na tohle tema psal, ze nema smysl vest nejake intelektualni seance a je treba se obratit na plan analyzer -> ten ti rozlozi dotaz bez ohledu na mnozstvi dat a ukaze, jestli tam nemas nejakou botu a neleze ti z toho napr. full scan kvuli absenci indexu.

A o tom, jake indexy a jak optimizer pouzije uz je otazka optimalizace na konkretnim RDBMS a pokud nemas data, jedna se o premature optimalizaci.
V danem pripade, pokud je FK unikatni, tak ma nejnizsi selektivitu a tudiz nema smysl mu pridavat dalsi podminky.

[Stanislav Hruška]

Uz jsem ti na tohle tema psal, ze...

Áno, len nedávno. Myslím na to. Posledná veta je to čo, som chcel vedieť.
Ďakujem.
Žiaľ, v niektorých prípadoch mám Natural a neviem sa ho zbaviť. Utešujem sa skutočnosťou, že tam bude maximálne pár tisíc záznamov.
Napríklad:

Kód: [Vybrat]

Plan:
PLAN JOIN (SORT (JOIN (SR N NATURAL, SR I_S INDEX (FK_INVOICE_SAC_SERPAR))), JOIN (SP INDEX (PK_SERVICEPARAMETERS), N INDEX (FK_Z_CONS_NUMBER_SEPA, FK_Z_CONS_NUMBER_ANOP,
 FK_Z_CONS_NUMBER_SAC)))
Adapted plan:
PLAN JOIN (SORT (JOIN (SR N NATURAL, SR I_S INDEX (FK_INVOICE_SAC_SERPAR))), JOIN (SP INDEX (PK_SERVICEPARAMETERS), N INDEX (FK_Z_CONS_NUMBER_SEPA, FK_Z_CONS_NUMBER_ANOP,
 FK_Z_CONS_NUMBER_SAC)))Predpokladám, že sa týka indexu SR I_S INDEX (FK_INVOICE_SAC_SERPAR))). Viď grafickú podobu dopytu.

[Stanislav Hruška]

Ešte dodatok, že optimalizáciu ešte len budem robiť nad vygenerovanými testovacími údajmi. Žiaľ, pri zostavovaní dopytov som nepoužíval kontrolu analyzátorom - plánom. To som ho ešte nemal, ani som o niečom takom netušil.

[Palino]

Ak v datach/vysledku nie je rozdie medzi

WHERE FKSERPAR = :FKSERPAR  vs. WHERE FKFOCS = :FKFOCS AND YEARS = :YEARS AND FKSERPAR = :FKSERPAR

co znaci ze FKSERPAR je jednoznacny (podmienka na YEARS a FKSERPAR neomedzi vysledok),  nema vyznam pridavat dalsie podmienky (prida pracu porovnavat udaje ktore vobec netreba porovnavat). Hlavne pri pridani stlpcov ktore nie su indexovane (moj predpoklad years) a server musi pristupit priamo na udaj s hodnotou na datovu stranku v DBsubore.

[Jan Fiala]

WHERE ma smysl rozsirovat, pokud existují na podmínku indexy, ktere ti omezi rozsah dat - hlavne clustrovany index. Relace (cizi klice) jako index neslouzi.

[pf1957]

Relace (cizi klice) jako index neslouzi.

Jasne, napr. u MSSQL vedle FK constraintu musis extra nadefinovat index.

Ale mam dojem, ze zrovna u FB to tak neni, ze tam se FK contraint definuje jako index a RDBMS ho jako index automaticky pouzije. Ale uz je to dlouho, co jsem s FB neco delal a nemam ji ani ninstalovanou, abych se podival, jak to vypadalo v projektech, kde jsme ji pouzivali.

[vandrovnik]

Relace (cizi klice) jako index neslouzi.

Jasne, napr. u MSSQL vedle FK constraintu musis extra nadefinovat index.

Ale mam dojem, ze zrovna u FB to tak neni, ze tam se FK contraint definuje jako index a RDBMS ho jako index automaticky pouzije.

Ano, je to tak, Firebird umí FOREING KEY použít jako index:

Kód: [Vybrat]

Plan
PLAN (A INDEX (RDB$FOREIGN279))


[Palino]

Ano moja odpoved patrila k Firebird (na zaklade ukazky planu v prispevku vyssie). FIREBRID aut. vytvara index pre kazdy FOREING KEY  z dovodu efektivnej kontroly pri aktivnych operacia updade/delete  tabulky na ktoru odkazuje.
"Ale mam dojem, ze zrovna u FB to tak neni, ze tam se FK contraint definuje jako index a RDBMS ho jako index automaticky pouzije. " -  index FIREBIRD pouzije na zaklade toho ze ho optimalizator vyhodnotil ako najlepsie riesenie  (napr. hodnota Statistic pre index) a nie na zaklade toho ze ide FOREING KEY.

[martinnr]

Teraz mám veľmi malý počet v záznamov. Takže žiaden rozdiel nezistím.

Taky Flamerobin ma generator dat. V urcitych pripadoch (ak netreba moc poli naplnat), tak moze posluzit, vygenerovat aj 100-ky tis. zaznamov s nahodnymi datami, na testy.