XML
Emil J.
2010/11/25 Emil J. <eak...@gmail.com>:
> Pozdravujem,Když není po ruce už nic jiného. Když výsledný dotaz oříznete na
>
> mozem sa opytat, ze na co sa teda pouziva ten OFFSET, ked na tuto vec nie
> je vhodny ?
>
serveru, tak je to řádově rychlejší než na straně klienta - radikálně
to redukuje objem přenesených dat. Bez problémů se nechá použít pro
jednorázové operace. Používá se pro eliminaci maximálních hodnot.
Např. MySQL nepodporuje kurzory, tudíž pokud chcete pracovat s
extrémně velkou tabulkou tak Vám nic jiného nezbude, než použít
OFFSET. V PostgreSQL ale kurzory jsou - což je extrémně užitečný
nástroj, když na klientu zpracováváte několika miliónové a větší
tabulky.
Rozhodně ale tato klauzule nebyla určena pro podporu stránkování - a
to, že OFFSETem lze stránkování řešit, zdaleka neznamená, že je to
optimální řešení (záleží na zatížení serveru, objemu dat, designu
aplikace). Většinou je výhodnější použít cache a nějakým způsobem
limitovat velikost výsledku. Neznám uživatele, který by se důkladně
věnoval datům a proklikal se na 100 stránku, natož pak na 1000.
Pavel
p.s. rada klauzulí v SQL je "k ničemu" - resp. jejích smysl a účel je
diskutabilní - např. NATURAL JOIN. CROSS JOIN, který se dříve docela
používal dneska až na výjimky lze většinou nahradit efektivnější
konstrukcí, ...
> Dakujem,
> Emil.
>
> 2010/11/25 Pavel Stehule <pavel....@gmail.com>
>>
>> 2010/11/25 Pavel Arnošt <id98...@gmail.com>:
>> > Zdravím,
>> >
>> > dotaz:
>> >
>> > SELECT id FROM reading ORDER BY timestamp OFFSET 125000 LIMIT 50
>> >
>> > jde docela pomalu, u mě na Win32/9.0.1 kolem 7-mi vteřin. Je to
>> > normální? Jde s tím něco dělat?
>> >
>> > Plán vypadá takhle:
>> >
>> > "Limit (cost=262611.53..262716.58 rows=50 width=209)"
>> > " -> Index Scan using reading_timestamp on reading
>> > (cost=0.00..8349830.29 rows=3974421 width=209)"
>> >
>> > Čím větší OFFSET, tím je to horší. A třeba u OFFSETu 500000 se změní i
>> > plán na:
>> >
>> > "Limit (cost=1004610.22..1004610.35 rows=50 width=209)"
>> > " -> Sort (cost=1003360.22..1013296.27 rows=3974421 width=209)"
>> > " Sort Key: "timestamp""
>> > " -> Seq Scan on reading (cost=0.00..160181.21 rows=3974421
>> > width=209)"
>> >
>> > a dotaz pak trvá 214 vteřin.
>> >
>> > Myslel jsem si že díky indexu bude dotaz magicky a rychle fungovat,
>> > ale něco mi uniká..
>>
>> Však se můžete přesvědčit, že s indexem dotaz trvá cca 7 sec a bez něj
>> 214. To, co Vám uniká, je pochopení jak funguje OFFSET a LIMIT. Tyto
>> klauzule (většinou) pouze seříznou výsledek dotazu. Klauzule OFFSET
>> samotný dotaz nijak neurychlí - OFFSET 0 LIMIT 50 -> po prvních 50
>> řádcích ukonči dotaz, OFFSET 10000 LIMIT 50 znamená, generuj 10050
>> řádků, prvních 10000 zahoď a klientu pošli 50 řádků. To je šíleně
>> neefektivní a samozřejmě, se zvyšujícím offsetem se dotaz zpomaluje.
>>
>> Před 2 lety jsem napsal bulvární článek do roota jak špatné je
>> používat LIKE. Mám pocit, že teď už tou špatnou klauzulí v SQL je
>> OFFSET :).
>>
>> Úplně by postačilo, kdybyste si pamatoval poslední hodnotu z předchozí
>> stránky - tj. místo offsetu napíšete
>>
>> SELECT FROM tab WHERE id > last_id ORDER BY id LIMIT 50.
>>
>> Další možností je použití kurzoru na straně serveru - díky kterému
>> můžete ze serveru sekvenčně odebírat bloky dat, aniž byste musel
>> opakovaně provádět dotaz. Nevím, proč děláte, to co děláte - jestli
>> stránkování www aplikace, tak to máte určitě nevhodně navržené - ani
>> google - a ten má rychlé stroje, a data v paměti Vám neumožní skočit
>> na 1000 stránku přímo.
>>
>> Pavel
>>
>> >
>> > Díky,
>> > S pozdravem
>> > Pavel Arnošt
>> >
>> > --
>> > Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
>> > PostgreSQL-cz ve Skupinách Google.
>> > Chcete-li přidat příspěvek do této skupiny, odešlete e-mail na adresu
>> > postgr...@googlegroups.com.
>> > Chcete-li se odhlásit z této skupiny, pošlete e-mail na adresu
>> > postgresql-c...@googlegroups.com.
>> > Další možnosti lze nastavit při návštěvě skupiny na stránce
>> > http://groups.google.com/group/postgresql-cz?hl=cs.
>> >
>> >
>>
>> --
>> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
>> PostgreSQL-cz ve Skupinách Google.
>> Chcete-li přidat příspěvek do této skupiny, odešlete e-mail na adresu
>> postgr...@googlegroups.com.
>> Chcete-li se odhlásit z této skupiny, pošlete e-mail na adresu
>> postgresql-c...@googlegroups.com.
>> Další možnosti lze nastavit při návštěvě skupiny na stránce
>> http://groups.google.com/group/postgresql-cz?hl=cs.
>>
>
> --
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> PostgreSQL-cz ve Skupinách Google.
> Chcete-li přidat příspěvek do této skupiny, odešlete e-mail na adresu
> postgr...@googlegroups.com.
> Chcete-li se odhlásit z této skupiny, pošlete e-mail na adresu
> postgresql-c...@googlegroups.com.
> Další možnosti lze nastavit při návštěvě skupiny na stránce
> http://groups.google.com/group/postgresql-cz?hl=cs.
>
--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
Chcete-li přidat příspěvek do této skupiny, odešlete e-mail na adresu postgr...@googlegroups.com.
Chcete-li se odhlásit z této skupiny, pošlete e-mail na adresu postgresql-c...@googlegroups.com.
Další možnosti lze nastavit při návštěvě skupiny na stránce http://groups.google.com/group/postgresql-cz?hl=cs.
t...@fuzzy.cz
nikdy jsem to nepotřeboval ale letmým pohledem do dokumentace se mi zdá že
by to mělo jít například funkcí "xpath" - viz.
http://www.postgresql.org/docs/9.0/interactive/functions-xml.html
a dokonce si na tom můžete udělat index.
Tomáš
> Chcel by som sa este nieco opytat.
> Zatial len v teoretickej rovine - mal by som takuto tabulku:
>
> *ID* BIGINT
> *XML_FIELD* napr. CHAR(1000)
>> >> > postgresql-c...@googlegroups.com<postgresql-cz%2Bunsu...@googlegroups.com>
>> .
>> >> > Další možnosti lze nastavit při návštěvě skupiny na stránce
>> >> > http://groups.google.com/group/postgresql-cz?hl=cs.
>> >> >
>> >> >
>> >>
>> >> --
>> >> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
>> >> PostgreSQL-cz ve Skupinách Google.
>> >> Chcete-li přidat příspěvek do této skupiny, odešlete e-mail na adresu
>> >> postgr...@googlegroups.com.
>> >> Chcete-li se odhlásit z této skupiny, pošlete e-mail na adresu
>> >> postgresql-c...@googlegroups.com<postgresql-cz%2Bunsu...@googlegroups.com>
>> .
>> >> Další možnosti lze nastavit při návštěvě skupiny na stránce
>> >> http://groups.google.com/group/postgresql-cz?hl=cs.
>> >>
>> >
>> > --
>> > Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
>> > PostgreSQL-cz ve Skupinách Google.
>> > Chcete-li přidat příspěvek do této skupiny, odešlete e-mail na adresu
>> > postgr...@googlegroups.com.
>> > Chcete-li se odhlásit z této skupiny, pošlete e-mail na adresu
>> > postgresql-c...@googlegroups.com<postgresql-cz%2Bunsu...@googlegroups.com>
>> .
>> > Další možnosti lze nastavit při návštěvě skupiny na stránce
>> > http://groups.google.com/group/postgresql-cz?hl=cs.
>> >
>>
>> --
>> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
>> PostgreSQL-cz ve Skupinách Google.
>> Chcete-li přidat příspěvek do této skupiny, odešlete e-mail na adresu
>> postgr...@googlegroups.com.
>> Chcete-li se odhlásit z této skupiny, pošlete e-mail na adresu
>> postgresql-c...@googlegroups.com<postgresql-cz%2Bunsu...@googlegroups.com>
Jiří Škopík
> Chcel by som sa este nieco opytat.
> Zatial len v teoretickej rovine - mal by som takuto tabulku:
>
> *XML_FIELD* napr. CHAR(1000)
> dajme tomu, ze v tabulke by bolo 100-tisic zaznamov
>
> Moje otazky su nasledovne:
>
> - mozem z toho XML vybrat hodnotu nejakej polozky ?
> napriklad XML obsahuje polozku sirka: .... <Sirka>100.2</Sirka> ...
> viem cez SELECT dostat tu SIRKU z XML do stlpca ?
xpath_bool), ale mám s ní špatnou zkušenost (pod Windows) - brutálně
žere paměť a když se v jednom selectu použije tak 100000×, spolehlivě
shodí server s chybou Out of memory (myslím, že to není normální, bude
tam nějaká chyba). Takže pro tento účel používám xslt_process, ta je v
pohodě, ale je potřeba si na to napsat funkci a XSL šablonu.
>
> - je na pristup do poloziek XML potrebna nejaka nastavba do postgresql,
> alebo su tam uz nejake funkcie implementovane ?
>
> - bolo by to pouzitelne (dostatocne rychle), keby som do WHERE dal podmienky
> pre polozky z XML ?
> napriklad: WHERE (SIRKA >= 100) (pricom tu hodnotu SIRKA by som vytiahol
> napr. nejakou funkciou z XML, z polozky XML_FIELD)
>
> jedna sa mi o to, ze XML_FIELD moze pre kazdy zaznam obsahovat ine polozky
> (jeden moze mat 'SIRKA', iny 'DLZKA', iny 'RYCHLOST' a kadeco) v samej
> podstate, kazdy zaznam by mohol mat v XML_FIELD ine polozky. ja by som
> potreboval vybrat take zaznamy z tabulky, ktore obsahuju prislusnu polozku a
> ta polozka ma nejaku hodnotu.
>
> Dakujem za info,
> Emil.
>
>
> > 2010/11/25 Emil J. <eakt...@gmail.com>:
>
> > >> 2010/11/25 Pavel Arnošt <id9848...@gmail.com>:
> > .
> > >> >http://groups.google.com/group/postgresql-cz?hl=cs.
>
> > >> --
> > >> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> > >> PostgreSQL-cz ve Skupinách Google.
> > >> Chcete-li přidat příspěvek do této skupiny, odešlete e-mail na adresu
> > >> postgr...@googlegroups.com.
> > >> Chcete-li se odhlásit z této skupiny, pošlete e-mail na adresu
> > .
> > >>http://groups.google.com/group/postgresql-cz?hl=cs.
>
> > > --
> > > Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> > > PostgreSQL-cz ve Skupinách Google.
> > > Chcete-li přidat příspěvek do této skupiny, odešlete e-mail na adresu
> > > postgr...@googlegroups.com.
> > > Chcete-li se odhlásit z této skupiny, pošlete e-mail na adresu
> > .
> > >http://groups.google.com/group/postgresql-cz?hl=cs.
>
> > --
> > Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> > PostgreSQL-cz ve Skupinách Google.
> > Chcete-li přidat příspěvek do této skupiny, odešlete e-mail na adresu
> > postgr...@googlegroups.com.
> > Chcete-li se odhlásit z této skupiny, pošlete e-mail na adresu
> > .
t...@fuzzy.cz
>> Chcel by som sa este nieco opytat.
>> Zatial len v teoretickej rovine - mal by som takuto tabulku:
>>
>> *ID* BIGINT
>> *XML_FIELD* napr. CHAR(1000)
>>
>> dajme tomu, ze v tabulke by bolo 100-tisic zaznamov
>>
>> Moje otazky su nasledovne:
>>
>> - mozem z toho XML vybrat hodnotu nejakej polozky ?
>> napriklad XML obsahuje polozku sirka: .... <Sirka>100.2</Sirka> ...
>> viem cez SELECT dostat tu SIRKU z XML do stlpca ?
> Dá se na to použít funkce xpath_string (případně xpath_number,
> xpath_bool), ale mám s ní špatnou zkušenost (pod Windows) - brutálně
> žere paměť a když se v jednom selectu použije tak 100000×, spolehlivě
> shodí server s chybou Out of memory (myslím, že to není normální, bude
> tam nějaká chyba). Takže pro tento účel používám xslt_process, ta je v
> pohodě, ale je potřeba si na to napsat funkci a XSL šablonu.
Která verze postgresql to je? S xml nepracuji, ale vím že dost podobných
problémů se opravilo v posledních verzích.
Tomáš
Jiří Škopík
Zkusil jsem teď tenhle pokus:
select xpath_number('<data>' || generate_series || '</data>','/data')
from generate_series(1,500000);
Na první pokus to projde, ale sežere to všechnu paměť a neuvolní ji,
na druhý pokus server spadne.
Jirka
Tomas Vondra
> D�l� mi to na 8.4.
> Zkusil jsem teďż˝ tenhle pokus:
> select xpath_number('<data>' || generate_series || '</data>','/data')
> from generate_series(1,500000);
> na druhďż˝ pokus server spadne.
> Jirka
Niiiice ... d�l� to i v 9.0.1. Nepamatuji se �e bych za posledn� dva
roky na po��ta�i pou�il swap ;-)
To �e se to neuvoln� ani po skon�en� procesu je IMHO chyba, nicm�n� do C
funkc� v PostgreSQL nevid�m natolik abych ho odhalil. Pavle?
Tomďż˝
Tomas Vondra
Trochu jsem se v tom vrtal a kouk�m �e ten xml2 contrib modul je
"deprecated" - nam�sto n�j je p��mo do core zabudovan� ekvivalentn�
funk�nost. Zkuste
select xpath('/data/text()', ('<data>' || generate_series ||
'</data>')::xml) from generate_series(1,500000);
to sice papďż˝ CPU ale nikoliv pamďż˝.
Tomďż˝
Pavel Stehule
> Dne 25.11.2010 11:54, Jiří Škopík napsal(a):
>> Dělá mi to na 8.4.
>> Zkusil jsem teď tenhle pokus:
>> select xpath_number('<data>' || generate_series || '</data>','/data')
>> from generate_series(1,500000);
>> Jirka
>
> Niiiice ... dělá to i v 9.0.1. Nepamatuji se že bych za poslední dva
> roky na počítači použil swap ;-)
>
> To že se to neuvolní ani po skončení procesu je IMHO chyba, nicméně do C
> funkcí v PostgreSQL nevidím natolik abych ho odhalil. Pavle?
>
tak minimalne ten memory leak je chyba - to, ze to sezere pamet a
nevrati (aniz by doslo k chybe) chyba je :(. Ale nejsem si jisty, jak
moc se v tom bude nekdo chtit vrtat. Je tam dost komplikaci ohledne
spravy pameti, ale je docela mozne, ze si zatim nikdo nevzal na paskal
funkci xpath_number.
Pavel
> Tomáš
>
> --
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
> Chcete-li přidat příspěvek do této skupiny, odešlete e-mail na adresu postgr...@googlegroups.com.
> Chcete-li se odhlásit z této skupiny, pošlete e-mail na adresu postgresql-c...@googlegroups.com.
t...@fuzzy.cz
>> Dne 25.11.2010 11:54, Jiří Škopík napsal(a):
>>> Dělá mi to na 8.4.
>>> Zkusil jsem teď tenhle pokus:
>>> select xpath_number('<data>' || generate_series || '</data>','/data')
>>> from generate_series(1,500000);
>>> Na první pokus to projde, ale sežere to všechnu paměť a neuvolní ji,
>>> na druhý pokus server spadne.
>>> Jirka
>>
>> Niiiice ... dělá to i v 9.0.1. Nepamatuji se že bych za poslední dva
>> roky na počítači použil swap ;-)
>>
>> To že se to neuvolní ani po skončení procesu je IMHO chyba, nicméně do C
>> funkcí v PostgreSQL nevidím natolik abych ho odhalil. Pavle?
>>
>
> tak minimalne ten memory leak je chyba - to, ze to sezere pamet a
> nevrati (aniz by doslo k chybe) chyba je :(. Ale nejsem si jisty, jak
> moc se v tom bude nekdo chtit vrtat. Je tam dost komplikaci ohledne
> spravy pameti, ale je docela mozne, ze si zatim nikdo nevzal na paskal
> funkci xpath_number.
Nikdo se v tom vrtat chtít nebude - je to deprecated, funkcionalitou to
plně nahrazují ty XML funkce zařazené do core a v těch ten memory leak
není.
Tomáš
Pavel Stehule
Jiri Skopik/8BC Ltd.
> From: postgr...@googlegroups.com [mailto:postgresql-
> c...@googlegroups.com] On Behalf Of Tomas Vondra
> Sent: Thursday, November 25, 2010 11:29 PM
> To: postgr...@googlegroups.com
> Subject: Re: XML
>
> Dne 25.11.2010 23:11, Tomas Vondra napsal(a):
> >> Dělá mi to na 8.4.
> >> Zkusil jsem teď tenhle pokus:
> >> select xpath_number('<data>' || generate_series ||
> '</data>','/data')
> >> from generate_series(1,500000);
> >> Jirka
> >
> > Niiiice ... dělá to i v 9.0.1. Nepamatuji se že bych za poslední dva
> > roky na počítači použil swap ;-)
> >
> > To že se to neuvolní ani po skončení procesu je IMHO chyba, nicméně
> do C
>
> Trochu jsem se v tom vrtal a koukám že ten xml2 contrib modul je
> "deprecated" - namísto něj je přímo do core zabudovaná ekvivalentní
> funkčnost. Zkuste
>
> select xpath('/data/text()', ('<data>' || generate_series ||
> '</data>')::xml) from generate_series(1,500000);
>
>
> Tomáš
Bezva, tohle vypadá použitelně.
Ale z xml2 používám ještě funkci xslt_process a tam žádnou náhradu nevidím. Navíc jsem s ní měl jeden problém, řešil jsem ho s Pavlem Stěhulem a ve verzi 9.1 by měla být oprava (viz http://archives.postgresql.org/pgsql-committers/2010-08/msg00120.php), takže úplně odepsaný ten modul asi ještě není?
Jirka
>
> --
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> PostgreSQL-cz ve Skupinách Google.
> Chcete-li přidat příspěvek do této skupiny, odešlete e-mail na adresu
> postgr...@googlegroups.com.
> Chcete-li se odhlásit z této skupiny, pošlete e-mail na adresu
> postgresql-c...@googlegroups.com.
Pavel Stehule
no vice-mene je. pokud jsem to spravne pochopil, tak tam je docela
problem se spravou pameti nad libxml2 - vrtalo se v tom dost lidi, a
jak je videt, tak to jeste nikdo nevyresil :( Jak je to s podporou
xslt nevim. Jestli je integrovana nebo ne. Ale verim tomu, ze bude
snaha tento modul zrusit.
Pavel
t...@fuzzy.cz
Ty SQL/XML funkce byly do core přidány už v 8.3 (měl bys to vědět, jsi u
toho uvedený v Release Notes ;-). Ale v principu máš pravdu, opravit by se
to asi mělo, už proto že některé ty funkce v core nejsou (např.
xslt_process, jak zmiňuje Jirka Škopík). Nicméně já to nejsem schopen
opravit, C jsem viděl asi tak před 10 lety.
Ostatně jak se to plánuje s podporou xml, resp. s tím xml2 modulem?
Evidentně je deprecated, tj. bude odstraněn, nicméně do core byla
přenesena jenom část funkcionality?
Tomáš
t...@fuzzy.cz
> problem se spravou pameti nad libxml2 - vrtalo se v tom dost lidi, a
> jak je videt, tak to jeste nikdo nevyresil :( Jak je to s podporou
> xslt nevim. Jestli je integrovana nebo ne. Ale verim tomu, ze bude
> snaha tento modul zrusit.
Včera jsem trochu googlil a hledal v archivech konferencí, a narazil jsem
na vlákno ve které se Tom Lane zmiňoval že když v libxml2 dojde k chybě
tak se neuvolní paměť nebo tak něco. Jj, s pamětí jsou akorát problémy -
kéž by v počítačích nic takového nebylo, svět by byl hned krásnější.
Nicméně měl jsem pocit že ta XML funkcionalita v jádře je také založena na
libxml2, a žádné leaky to tam nemá, ne?
Tomáš
Pavel Stehule
ono se to dost prekopalo. ten memory leak v xml2 je docela dost
hloupej - pravdepodobne pochozi z nejakeho spatne udelaneho bugfixu. V
priloze je fix.
> Tomáš
t...@fuzzy.cz
>>> 2010/11/26 Jiri Skopik/8BC Ltd. <sko...@8bc.com>:
>>> no vice-mene je. pokud jsem to spravne pochopil, tak tam je docela
>>> problem se spravou pameti nad libxml2 - vrtalo se v tom dost lidi, a
>>> jak je videt, tak to jeste nikdo nevyresil :( Jak je to s podporou
>>> xslt nevim. Jestli je integrovana nebo ne. Ale verim tomu, ze bude
>>> snaha tento modul zrusit.
>>
>> Včera jsem trochu googlil a hledal v archivech konferencí, a narazil
>> jsem
>> na vlákno ve které se Tom Lane zmiňoval že když v libxml2 dojde k chybě
>> tak se neuvolní paměť nebo tak něco. Jj, s pamětí jsou akorát problémy -
>> kéž by v počítačích nic takového nebylo, svět by byl hned krásnější.
>>
>> Nicméně měl jsem pocit že ta XML funkcionalita v jádře je také založena
>> na
>> libxml2, a žádné leaky to tam nemá, ne?
>>
>
> ono se to dost prekopalo. ten memory leak v xml2 je docela dost
> hloupej - pravdepodobne pochozi z nejakeho spatne udelaneho bugfixu. V
> priloze je fix.
Fajn. Zareportujes to na pgsql-bugs? Ja bych to udelal, nicmene nevim
presne v cem ta chyba je a nechci se chlubit cizim perim.
Tomas
Pavel Stehule
uz jsem do pg_hackers poslal fix.
nicmene bude lepsi, kdyz to zaregistrujes na pg_bugs ty. O mne vsichni
vedi, ze nejsem uzivatel :)
Pavel
>
> Tomas
Pavel Stehule
viz http://archives.postgresql.org/pgsql-hackers/2010-11/msg01798.php
prosim, kdyz narazite na podobnou chybu, tak ji reportujte. Nektere
veci lze opravit pomerne snadno, a muze to pomoci dalsim lidem.
Zdarek
Pavel
Dne 26. listopadu 2010 11:23 Pavel Stehule <pavel....@gmail.com> napsal(a):
t...@fuzzy.cz
> veci lze opravit pomerne snadno, a muze to pomoci dalsim lidem.
Ámen!
Tomáš