Uloženo je to jako text. Což má daleko do ideálu. To parsování bych překousl, stejně je potřeba index, ale u krátkých xml <2kB je zbytečná redundance .. pokud, ke sloupci definujete DTD, tak můžete místo tagů ukládat tokeny. S delšími xml není problém, tam automaticky nastoupi gz komprimace všech textů. Libxml2 nepodporuje binární formát, i když to by se mohlo letos změnit. Co je opravdu minimalistické je podpora XPath. XPath je podporováno plně jako jazyk, tak jak je podporuje libxml2, není však podporováno GiST ani GiN indexem .. XPath vyžaduje rekurzivní vícerozměrný index. Nechybí ale podpora funkcionálního indexu, takže konstatní XPath dotazy lze provést relativně rychle .. funkcionální index udržuje výsledek, takže nedochází k parsování:
Efektivnější implementací operace se může dosáhnout cca 100% zrychlení, což v databázích moc neznamená. Větší vliv by měla interní implementace XPath včetně podpory planneru a zmínil jsem multidimenzionálního rekurzivního indexu. Bez podpory libxml2 to v žádném případě hned tak nebude. XPath je principiálně duplicitní dotazovací jazyk k SQL a mít dvě dotazovací jádra není udržitelné. Oleg Bartunov, což je jeden z autorů TSearch2 má v ToDo jak určitou akceleraci XPath dotazů, tak skutečně nativní XML datový typ. Jestli bude nebo nebude je ve hvězdách.
Ona podpora XML v PostgreSQL je dost velká partyzánština několika málo evropanů, kterou jsem začal já napsáním prototypu SQL/XML. Konferenci sleduji skutečně pozorně, a s tímto požadavkem se ozvali 3-4 uživatelé. Takže jsem docela čekal, že se XML vůbec v pg neobjeví. Nakonec je to jedna z hlavních fíčur 8.3 :). Rozhodně SQL/XML zůstane, záleží ale na reakcích uživatelů zda-li to budou používat a s jakým výsledkem. Pokud to uživatelé budou používat, tak se vyplatí pracovat dále na podpoře, pokud ne, tak to zůstane tak jak je.
ČLÁNKY DO MAILU