hejch:
. IN ti dotaz nezrychlí.
To bych se hádal. Načtění X záznamů z databáze najednou oproti načítání řádek po jednom zrychlí přístup do databáze v podstatě vždy. To je můj "denní chleba".
kit:
Že je IN ptákovinou, jsem zjistil po prvním benchmarku, ve kterém propadl.
Nejlepších výsledků jsem dosáhl, když jsem data nahrál do dočasné tabulky a provedl JOIN. Indexy zafungovaly a jelo to jako blesk.
Co já mám (s postrgresem) zkušenosti, tak hromadné načtení záznamů pomocí IN je vždy rychlejší, než načítání "po jednom", a nijak výkonnostně netrpí.Naházení do dočasné tabulky se dá udělat i jednodušeji pomocí
WITH data AS (
VALUES (....),(...)
)
SELECT .....
ale nevidím důvod, proč by takovýto join měl proběhnout rychleji než operátor IN. Co jsem si teď zkusil na svejch malejch datech, tak IN byl rychlejší než JOIN (0.100-0.300ms versus 0.400-0.800ms), a lišili se i trochu v plánech (IN použil bitmap index scan, zatímco JOIN použil jen čistej index scan). Pokud jsem použil JOIN na temporary table, tak bez VACUUM ANALYZE na tu temporary table se použil sekvenční scan, po ANALYZE se použil stejnej plán, jako u JOINu na "WITH data AS ....".
Jaký výsledky a jaký plány to generuje Tobě?
Wangarg:
root.get_child(["0:Objects", "4:new_Controller_0", "3:GlobalVars", tag_string])
nie je tam asi 5000 premennych a ja musim citat zapisovat len konkretnu. S tymto si presne adresujes.
No podstata mého dotazu je, že začátek tý adresace je vždy stejný, takže by to mělo jít znova použít. Navíc, nejde náhodou o todle?
https://github.com/FreeOpcUa/python-opcua/Pokud ano, tak opravdu po stromě lezeš (jen to nevíš :-)), takže můžeš na začátku vyselektit ten 3:GlobalVars a pak už jen hledat ten podřízenej nod podle tagu. Ale třeba se pletu?