<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
	<channel>
		<title><![CDATA[Forum PostgreSQL - Mini porównanie - ktoś może wytłumaczy mi...]]></title>
		<link>https://forum.postgresql.org.pl/viewtopic.php?id=555</link>
		<description><![CDATA[Najświeższe odpowiedzi w Mini porównanie - ktoś może wytłumaczy mi....]]></description>
		<lastBuildDate>Tue, 08 Mar 2011 19:48:50 +0000</lastBuildDate>
		<generator>PunBB</generator>
		<item>
			<title><![CDATA[Odp: Mini porównanie - ktoś może wytłumaczy mi...]]></title>
			<link>https://forum.postgresql.org.pl/viewtopic.php?pid=2419#p2419</link>
			<description><![CDATA[Czym się rózni OID od SERIAL? wszystkim :).

OID służy bardziej postgresowi do m innymi łączenia tabel. Wszystkie (chyba wszystkie) fizyczne obiekty w postgresie mają swój unikalny numer (OID) i to z tych numerów korzysta postgres odwołując się do tabel/indeksów.
OID moga być też przypisane do wierszy w tabelach (podczas tworzenia tabeli możesz powiedzieć że każdy wiersz ma mieć swój wygenerowany OID, opcja 'WITH OIDS') i wtedy, taki oid może się przydać gdy chcesz usunąć jakiś dublujące się wiersze z tabeli.
Ogólnie rzecz biorąc OID to maksymalne liczba 4 bajtowa, więc może się kiedyś przepełnić i wtedy będzie będzie koniec świata :).

Więcej o OID'ach i innych *ID'ach znajdziesz tu
[url]http://www.postgresql.org/docs/9.0/static/datatype-oid.html[/url]]]></description>
			<author><![CDATA[dummy@example.com (rski)]]></author>
			<pubDate>Tue, 08 Mar 2011 19:48:50 +0000</pubDate>
			<guid>https://forum.postgresql.org.pl/viewtopic.php?pid=2419#p2419</guid>
		</item>
		<item>
			<title><![CDATA[Odp: Mini porównanie - ktoś może wytłumaczy mi...]]></title>
			<link>https://forum.postgresql.org.pl/viewtopic.php?pid=2418#p2418</link>
			<description><![CDATA[explaina mam sformatowanego w pgadminIII. Nie rozumiem tego, co jest wyświetlane, zwłaszca informacji typu:
[code]Sort (cost=129344.37..129354.40 rows=4013 width=1418) (actual time=21377.760..21378.441 rows=4485 loops=1)[/code]

Jeszcze dodatkowo jest dość ciekawie wyświetlony "histogram"... Na pewno dojdę kiedyś co i jak:)

Jestem bardziej praktykiem, niż teoretykiem i dokumentacja póki co jest strasznie skomplikowana, zwłaszcza przez m.in. inne nazewnictwo w stosunku do mysql. Póki co próbuję różnorakie zapytania, aby nauczyć się co jest inaczej w postgres. No i jeszcze coś się muszę dowiedzieć o tych indexach (które jak wyczytałem raz są używane w wyszukiwaniu, raz nie, a czasem trzeba je rzutować na int(8) - porypane...

Teraz pytanie:
[code]
SELECT * FROM elements ORDER BY OID;
[/code]
w jakiej kolejności to pobiera?
czym to się różni od (id - serial):
[code]
SELECT * FROM elements ORDER BY id;
[/code]

OID to rozumiem - coś, [b]co może mnie wcale nie interesować[/b] - jest to coś (obiekt?) definiujący unikalnie dowolny obiekt w bazie (jak tabela). Jeśli takie coś jest w tabeli i mogę wykonać sortowanie po oid - to rozumiem, że wyniki zostaną pobrane w kolejności wkładania do bazy?

Niestety nie mam możliwości przetestowania teraz tego:( Grzebię w dokumentacji na sucho...]]></description>
			<author><![CDATA[dummy@example.com (aleextra)]]></author>
			<pubDate>Tue, 08 Mar 2011 07:26:59 +0000</pubDate>
			<guid>https://forum.postgresql.org.pl/viewtopic.php?pid=2418#p2418</guid>
		</item>
		<item>
			<title><![CDATA[Odp: Mini porównanie - ktoś może wytłumaczy mi...]]></title>
			<link>https://forum.postgresql.org.pl/viewtopic.php?pid=2417#p2417</link>
			<description><![CDATA[[quote]
Czym są indexy dla postgresa? Czy różni się to od mysql?
[/quote]
Są indeksy typu B-tree, Hash, Gin, Gist
Są też indeksy funkcyjne i częściowe
[url]http://www.postgresql.org/docs/9.0/interactive/sql-createindex.html[/url]

[quote]
Czy różni się to od mysql?
[/quote]
Pewnie że się różni, jest lepszy :).

[quote]
Czy zwracać  uwagę na typ indexu? Czy obojętne czy jest to int, czy varchar oraz czy ma znaczenie wielkość tego inta?
[/quote]
Tego pytania chyba nie rozumiem. ogólnie dla kolumn skalarnych pewnie będziesz używał tylko indeksu btree (jest domyślny).

[quote]
Czemu explain query jest tak skomplikowane??
[/quote]
No cóż nie może być za łatwo. Rzuć okiem na to [url]http://explain.depesz.com/[/url] może ci się spodoba.]]></description>
			<author><![CDATA[dummy@example.com (rski)]]></author>
			<pubDate>Mon, 07 Mar 2011 19:17:17 +0000</pubDate>
			<guid>https://forum.postgresql.org.pl/viewtopic.php?pid=2417#p2417</guid>
		</item>
		<item>
			<title><![CDATA[Odp: Mini porównanie - ktoś może wytłumaczy mi...]]></title>
			<link>https://forum.postgresql.org.pl/viewtopic.php?pid=2416#p2416</link>
			<description><![CDATA[Pozwolę sobie napisać  w osobnym wątku...

Czym są indexy dla postgresa? Czy różni się to od mysql?
Czy zwracać  uwagę na typ indexu? Czy obojętne czy jest to int, czy varchar oraz czy ma znaczenie wielkość tego inta?
Czemu explain query jest tak skomplikowane?? :) Muszę o tym poczytać. Jakoś w mysql łatwiej mi było się w tym połapać (w sumie od razu wiedziałem).]]></description>
			<author><![CDATA[dummy@example.com (aleextra)]]></author>
			<pubDate>Mon, 07 Mar 2011 18:45:10 +0000</pubDate>
			<guid>https://forum.postgresql.org.pl/viewtopic.php?pid=2416#p2416</guid>
		</item>
		<item>
			<title><![CDATA[Mini porównanie - ktoś może wytłumaczy mi...]]></title>
			<link>https://forum.postgresql.org.pl/viewtopic.php?pid=2415#p2415</link>
			<description><![CDATA[Witam!
Przygotowuję się do skoku z mysql na postgresql. Zrobiłem małą próbę.. 4 tabele...

operators: 100 wierszy, 
groups: 972 wiersze,
elements: 53044 wierszy
payment: 132583 wierszy

Zależność (mniej więcej taka jaką potrzebuję tylko w uproszczeniu):
operatorzy mają różną ilość grup w sobie, do każdej grupy przypisane są elementy (osoby) które mają swój bilans w tabeli payment. Bilans to wpłata (kolumna ma), lub wypłata (kolumna winien). Dodatkowo płatności podzielone są na roczniki - ich id to losowo we wpłatach liczba między 1-4

czyli w każdej tabeli podrzędnej przechowywany jest id nadrzędny (jako parent_id czy coś takiego).

Mysql: innoDB, postgres - nie mam pojęcia póki co. Może nawet postgres nie ma różnych silników - nie interesuje mnie to, byleby transakcje, triggery i widoki obsługiwał.
[code]

CREATE TABLE operators
(
  id serial NOT NULL,
  nazwa character varying(64),
  CONSTRAINT operators_pkey PRIMARY KEY (id)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE operators OWNER TO mik;

CREATE TABLE groups
(
  id serial NOT NULL,
  parent_id integer,
  nazwa character varying(64),
  CONSTRAINT groups_pkey PRIMARY KEY (id)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE groups OWNER TO mik;

CREATE TABLE elements
(
  id serial NOT NULL,
  parent_group integer,
  nazwa character varying(64),
  CONSTRAINT elements_pkey PRIMARY KEY (id)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE elements OWNER TO mik;

CREATE TABLE payment
(
  id serial NOT NULL,
  child_id integer,
  ma integer DEFAULT 0,
  winien smallint DEFAULT 0,
  rocznik smallint,
  CONSTRAINT primary_key PRIMARY KEY (id)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE payment OWNER TO mik;

-- Index: "Rocznik"

-- DROP INDEX "Rocznik";

CREATE INDEX "Rocznik"
  ON payment
  USING btree
  (rocznik);
[/code]

Tabele uzupełnione przez skrypt php (wielokrotnie.. ale początkowo miało byc operatorów 800 i dużo więcej danych - lecz miejsce na dysku mi się skończyło... więc zmniejszyłem próbkę).

Pierwsze na co zwróciło mi uwagę - obciążenie procesora - postgres zużywa średnio 6% więcej procka niż mysql, lecz mysql zapisuje dużo więcej danych na dysku niż postgres.
Zrzut ekranu wyjaśni wszytko:
[url=http://img37.imageshack.us/i/zrzutekranu12b.png/][img]http://img37.imageshack.us/img37/803/zrzutekranu12b.th.png[/img][/url]

Uploaded with [url=http://imageshack.us]ImageShack.us[/url]

dla wyjaśnienia - mysql i postgres świeżo instalowane. Z powodu moich błędów, prób z zapytaniami postgres kilkukrotnie wykonywałem truncate na tabelach:) Mysql za bardzo nie chce oddać przestrzeni dyskowej jaką zajmuje... i tylko się wielkość kumuluje:(

W czasie testów zapytań - index na payment został dodany dzisiaj - aby przetestować wydajność.
Niektóre zapytania nic nie dają - żadnych sensownych - chodziło mi o porównanie. 
[code]
postgresql    mysql
select count(*) from operators;
145,458    340
select count(*) from groups;
43,158    70
select count(*) from elements;
161,679    870
select count(*) from payment;
214,358    510
[/code]
czas przeliczyłem na ms (mysql podaje jako np. 0.34s = 340ms)
[code]
select COUNT(*), child_id from payment group by child_id;
postgresql    mysql
331,498    190
[/code]
[code]
select elements.nazwa, sum(payment.ma), sum(payment.winien)   
from elements, payment  where elements.id = payment.child_id  
Group by elements.id, elements.nazwa
postgresql    mysql
1682,131    3000

[/code]

różnica 10s na korzyść postgres
[code]
select elements.nazwa as ename, groups.nazwa as gname,  sum(payment.ma), sum(payment.winien)   
from elements, payment, groups  
where elements.id = payment.child_id  AND elements.parent_group = groups.id 
group by elements.id,  elements.nazwa, groups.nazwa
postgresql    mysql
2707,856    13410
[/code]

Dochodzimy do ciekawszych:
[code]
select elements.nazwa as ename, groups.nazwa as gname, operators.nazwa as oname, sum(payment.ma), sum(payment.winien)  
from elements, payment, groups, operators 
where elements.id = payment.child_id AND elements.parent_group = groups.id and groups.parent_id = operators.id 
group by elements.id, elements.nazwa, groups.nazwa, operators.nazwa

postgresql    mysql
3524,722    18050
jakby co.. różnica jest 15000ms na korzyść postgres
[/code]
O dziwo, drugie wywołanie powyższego zapytania wydłużyło czas na obu bazach:) Nie tego się spodziewałem...

Coraz ciekawiej:
dla przypomnienia - wtedy na tabeli payment nie było indexu
[code]
select elements.nazwa as ename, groups.nazwa as gname, operators.nazwa as oname, sum(payment.ma), sum(payment.winien)  
from elements, payment, groups, operators 
where elements.id = payment.child_id AND elements.parent_group = groups.id and groups.parent_id = operators.id and payment.rocznik='1' 
group by elements.id, elements.nazwa, groups.nazwa, operators.nazwa;


mysql postgres
6.22    556,558
----------------
po założeniu indexu
mysql    postgres 
10.03    587,54

[/code]

Ostateczne pogrążenie mysql (komentarz pod wynikami)
[code]
select elements.nazwa from elements left join payment on (payment.child_id = elements.id);
mysql 3min - zabiłem wątek po 3 minutach
postgresql: 270,598ms
[/code]

[code]
select elements.nazwa from elements left join payment on (payment.child_id = elements.id);
mysql 3min - zabiłem wątek po 3 minutach
postgresql: 270,598ms
[/code]
z grupowaniem
[code]
select elements.nazwa from elements left join payment on (payment.child_id = elements.id) group by elements.id,elements.nazwa
mysql > 2min, zabiłem wątek
postgres:     1536,819

[/code]

Dwa powyższe zapytania chyba raczej nigdy się nie zdarzą w rzeczywistości - przykładowo ja, jako programista php to zdecydowanie stwierdzam, że byłoby to ryzykowne - serwer ubiłby wątek ze względu na zużycie pamięci dostępnej dla wątka. Ale dla mnie, do oceny przydatności bazy danych postgres jest to istotny element. Popełniam czasem błędy  i miło wiedzieć, że po błędzie nie będę mieć spanikowanych głosów, że system nie działa - bo baza mieli jedno mordercze zapytanie.

[code]
Sytstem testowy
archlinux
kernel: 2.6.37 (prawdopodobnie bez patcha grupującego wątki)
core2duo 2GHz
mysql: 5.5.9
postgres: 9.0.3
[/code]

Także użytkownicy tego forum, możecie się bać - zadam nie jedno głupie pytanie... Przechodzę na postgresową stronę mocy.]]></description>
			<author><![CDATA[dummy@example.com (aleextra)]]></author>
			<pubDate>Mon, 07 Mar 2011 18:43:08 +0000</pubDate>
			<guid>https://forum.postgresql.org.pl/viewtopic.php?pid=2415#p2415</guid>
		</item>
	</channel>
</rss>
