Dotaz na optimalizaci - indexy

[Michal Měšťan]

Ing. Pavel Janousek wrote:

>	Dobry den,
>
>	dneska mne datove modelovani pekne vypeklo a uz se nevim rady...
>
>	Mam nasledujici model:
>
>table A (id, cas, ostatni atributy)
>table B (id, ostatni atributy)
>
>	Table A se plni v case postupne daty, table B se plni tak, ze
>jednou za cas (pravidelne) se prochazi table A a pokud obsahuje ID,
>ktere neni v table B, tak se radek zpracuje (= v table B vznikne dalsi
>radek).
>
>	Jiz drive jsem provedl optimalizaci v tom smyslu, ze se prochazi
>data jen od urciteho data (cas=now()).
>
>	Co mne vsak dostalo, tak tento dotaz:
>
>select id, ... from TableA where id not in (select id from TableB) and
>(now() - cas) < 3000000 order by cas desc;
>

Nemohlo by fungovat cosi takového? Teda pokud by se oželelo seřazení 
výsledku podle času nebo to seřadit až pak.

SELECT id, ... from TableA WHERE (now() - cas) < 3000000 EXCEPT SELECT 
id, ... from TableB (now() - cas) < 3000000;

nebo

SELECT id, ... from TableA WHERE (now() - cas) < 3000000 EXCEPT ALL 
SELECT id, ... from TableB (now() - cas) < 3000000;

>
>	Ta konstanta (3000000) odpovida zhruba 3 mesicum (aspon si to
>tak myslim/pamatuju).
>
>	Resim optimalizaci na PostgreSQL - explain v zakladni podobe
>povi:
>
>NOTICE:  QUERY PLAN:
>
>Sort  (cost=6087160.84..6087160.84 rows=4377 width=44)
>  ->  Seq Scan on TableA  (cost=0.00..6086896.15 rows=4377 width=44)
>        SubPlan
>          ->  Seq Scan on TableB (cost=0.00..463.51 rows=21251 width=4)
>
>	Chapu, ze spatne jsou ty sekvencni pruchody - ovsem to i na PIV
>1.6GHz neni zanedbatelne pri nasledujicim zaplneni (zpracovani je
>desitky minut) - explain vyse je na techto datech:
>
>Table A - 27 tisic zaznamu
>Table B - 21 tisic zaznamu
>
>	Takze jsem si zacal hrat s indexy, zkousel jsem indexovat jak
>samotne id v obou tabulkach, tak slozeny index z id+cas v tabulce 1.,
>presto planovac a PostgreSQL backend neni stale ochoten pouzit zadne
>tyto "donucovaci" prostredky pro optimalni praci...
>
>	Domnivam se, ze podobna situace neni neuveritelna konstrukce,
>ale ze podobnych pripadu je v praxi daleko vice, jak to resite v praxi
>Vy? Pripadne, co by mohlo pomoci? (datovy model - tabulky - menit
>nelze...)
>  
>
Měšťan