Dnia 2012-10-16, wto o godzinie 13:02 +0200, Tomasz Chiliński pisze: 
W dniu 16.10.2012 12:52, Marcin napisał(a):
> W dniu 16 października 2012 12:40 użytkownik Tomasz Chiliński
> <tomasz.chilinski@chilan.com> napisał:
>
>> A ja lubię tak pisać o MySQL, bo zawsze widzę przed oczami rzeszę 
>> ludzi
>> męczącą się z MySQL i mi ich trochę żal ;-)
>
> a ja Tomku zastanawiałem się nad przejściem na postgress właśnie m.in
> [1]. po Twoich postach. porównuje wyniki wydajności mysq vs. postgres
> i przyznam, że prawie, podkreślam "prawie", nic nie przemawia za
> postgres. Dodatkowo replikacja jest też sporo utrudniona.
>  żeby nie być gołosłownym pierwszy link porównujący bazy.
> 
> http://www.progresowi.pl/2011/11/10/porownujemy-wydajnosc-mysql-vs-postgresql-vs-mongodb.html
> [2]
>  oczywiście w starszych wersjach mysql to postgres wygrywał znacząco.
> teraz te różnice się zatarły.
>
> Twoim zdaniem, co konkretnie przemawia za postresem?

A i z tego co sobie przypominam przy tego typu testach MySQL zawsze był 
bardziej
wydajny niż PostgreSQL i nic dziwnego, bo jak powstawał to miał być 
czymś podobnym
do obecnie popularnego SQLite...
Do dziś MySQL ma tryb embedded!

> --
> Pozdrawiam
> Marcin / nicraM

to i ja dołożę swoje 3 grosze.

Wydajność bazy można oceniać jak mamy np. z 1 mln rekordów,
przy 3-4k to tak naprawdę decyduje jak jest napisane zapytanie SQL.

W LMS jest obsługa MySQL i PgSQL więc zapytania musza być "uniwersalne", a jak wiadomo co jest uniwersalne to jest do d...y, i w takim przypadku nie uzyskami 100% wydajności dla każdej z baz.

Kiedyś robiłem przeróbkę funkcji getcustomerlist pod kątem wydajności dla MySQL, przy 5k klientach, każdy z nich miał po 36 faktur czas generowania 1 strony był na poziomie 2.2 - 2.6(max) sek, (przy oryginalnym kodzie trwało to ponad 180 sekund, test na starej maszynce)
ale ta sama przeróbka w postgresie nie miała racji bytu, PG wysypywał się przy zapytaniu, dla niego była błędna składnia zapytania.

Jedyne co można w tej chwili zrobić dla MySQL to poprawić trochę strukturę bazy danych, typy pól, indexy'  itp. czy w niektórych tabelach przejść spowrotem na MyISSAM,
na podstawie własnych eksperymentów mogę powiedzieć że można to jeszcze bardziej zoptymalizować i efekty są widoczne.

Co przemawia (jak dla mnie) żeby używać PgSQL, lepsza wydajność przy bardzo złożonych zapytaniach, i to jest jedyna rzecz która mogła by mnie skłonić do używania tej bazy "trwale", pozostałe niuanse jakimi rządzi się PG , zwłaszcza przy dodawaniu/edycji rekordów , dość mocno zniechęcają do używania tej bazy, delikatnie mówiąc PgSQL w zapytaniach nie jest tak "debiloodporny" jak MySQL. (plus dla MySQL)

Na co dzień nie używam PG (tylko jak muszę) , więc nie wiem jak jest w tej chwili, ale swojego czasu (info z różnych for) PG lubił się wysypać, mi MySQL nie padł jeszcze.

Najlepszym rozwiązaniem by było : albo wybranie "jedynej słusznej bazy" i pod nią pisać zapytania , wtedy będzie można wycisnąć soki z bazy, albo pisać osobne zapytania dla MySQL i PgSQL,
ale jak życie pokazuje w/w rozwiązania mijają się realiami jakie mamy na co dzień.

MySQL jest naprawdę wydajną bazą, ale muszą być spełnione warunki :  struktura i zapytania muszą być zrobione pod tą bazę.

To tyle jeżeli chodzi o spojrzenie na bazy zwykłego śmiertelnika :D