PostgreSQL
radim.kubacki na rtscs.cz
radim.kubacki na rtscs.cz
Pátek Říjen 1 12:12:49 CEST 1999
> -----Původní zpráva-----
> Od: Pavel Kankovsky
> Odesláno: 1. října 1999 10:31
> Komu: linux na linux.cz
> Předmět: Re: PostgreSQL
>
> On Fri, 1 Oct 1999, Oto tapik Buchta wrote:
>
> > No mne by hlavne zajimalo, jestli ten dotycny vi, jak dlouho mu bude
> > trvat sort na 10^10 zaznamech. I pri slozitosti n.log(n) (zatim imho
> > nejlepsi, ceho se da dosahnout) je to neco kolem 10^11 kroku.
>
> Da se dokazat, ze O(n log n) je asymptoticky nejlepsi mozna slozitost,
> pokud se vyuziva pouze porovnavani prvku (to je btw dulezity
> predpoklad...ve specialnich situacich lze tridit i s linearni slozitosti).
>
> Dukaz je celkem jednoduchy: mame-li seznam n prvku, pak muze prijit v n!
> ruznych setridenich. Tj. algoritmus musi byt schopen provest n! ruznych
> permutaci, tj. musi provest alespon O(log n!) rozhodnuti, jak dal (na
> zaklade porovnani prvku), coz se za pouziti Stirlingova vzorce da
> prepocitat na O(n log n).
>
> Snad tato mala comp-sci odbocka nikomu nebude vadit.
>
Ja myslim, ze nevadi. Stoji za to uvedomit si ten predpoklad.
IMHO se ale trideni 10 miliard zaznamu v databazi nebude delat quicksortem,
i kdyz ten v prumeru pracuje O(n log n). Ty data se totiz nevejdou do pameti
a porovnavat je na disku a tam je i prehazovat je pekna blbost.
V praxi se asi pouzije merge-sort. Na zacatku setridim kousky, ktere se
vejdou do pameti a ty potom slevam ve vetsi kusy.
Anebo mam na to treba index (prip. si ho vytvorim, to se ale u trideni asi
nevyplati, u spojeni nekdy jo).
Celkove to ale urcite bude trvat dost dlouho, mozna to spocita za domaci
ukol. Myslim, ze iniciator tohoto threadu je uz z te myslenky vylecen.
Napsat aplikaci pracujici s takovym objemem dat neni uplna hracka. Snad mu
pokrok v hw pomuze. (Za par let :).)
Radim
Další informace o konferenci Linux