GoldenLine
Zaloguj się
Michał Płonka

Michał Płonka Programista PHP

Temat: [PostgreSQL] Indeks daty - timestamp vs date

Witam,
w tabeli w bazie PostgreSQL mam pole typu TIMESTAMP WITHOUT TIME ZONE. Generalnie nie potrzebuję w nim dokładności większej niż dzień więc w zupełności wystarczyłoby mi pole typu DATE. Przezornie jednak na razie zostawiłem jak jest.
Pytanie moje jest następujące: wyszukiwanie po tym polu odbywa się tylko i wyłącznie w "ramach" dni (czyli WHERE pole >= '2009-12-22') bez patrzenia na czas. To samo tyczy się grupowania: grupuję dane dla danych dni. Na polu tym mam założony indeks, który generalnie sprawdza się nieźle. Czy (biorąc pod uwagę brak znaczenia czasu z pola) lepszym wyjściem byłoby przerobienie pola na typ DATE? Jak to będzie wyglądało dla indeksu?
Czyli reasumując: czy odczuję jakąś większą korzyść podczas wyszukiwania po zmianie pola na typ DATE?

PS: Dodam, że zależy mi na jak najlepszej wydajności bazy. Dzienny przyrost bazy to ok. 500MB więc z każdym dniem kolejne modyfikacje będą trudniejsze.Michał Płonka edytował(a) ten post dnia 22.12.09 o godzinie 19:06
Link do wypowiedziLink
Daniel N.

Daniel N. Senior IT Architect,
DBA

Temat: [PostgreSQL] Indeks daty - timestamp vs date

Zgodnie z tą tabelą : http://www.postgresql.org/docs/8.2/static/datatype-dat...
typ Date zajmuje 4 bajty w przeciwieństwie do timestamp, który potrzebuje 8 bajtów. Wydaje mi się, że im mniej danych będzie użyte do przeszukiwania tym wydajniejszy będzie to proces. Więc jeśli nie potrzebujesz zakresu daty do mikrosekund myślę, że Date spokojnie wystarczy.
Proszę o skorygowanie mnie jeśli się mylę.
Link do wypowiedziLink
Łukasz Dudek

Łukasz Dudek Database
Administrator

Temat: [PostgreSQL] Indeks daty - timestamp vs date

'2009-12-12'::date == '2009-12-12 00:00:00'::datetime (+ ileśtam miejsc po przecinku )
dla indeksów btree (defaultowe) nie ma większego znaczenia w jakim formacie są dane o ile szukasz od początku pola.
Jeśli masz seq scany na tabeli to zmiana pomoże jeśli nie, nie ma to większego znaczenia .
Link do wypowiedziLink

konto usunięte

Temat: [PostgreSQL] Indeks daty - timestamp vs date

Skoro macie ( przynajmniej wg was ) takiego startup'a to może warto byłoby zwiększyć szeregi o kogoś, kto ma trochę doświadczenia w PG, bo po co parę dni po starcie kończyć jak Miller i zrażać do siebie użytkowników ;-)
Link do wypowiedziLink

konto usunięte

Temat: [PostgreSQL] Indeks daty - timestamp vs date

Wydaje mi się, że sensowne statystyki z użycia bazy danych pozwolą na określenie zestawu zapytań, których optymalizowanie ma największy sens.
No, ale komuś z praktyczną znajomością baz danych... chyba nie trzeba takich rzeczy tłumaczyć. Przepraszam za złośliwość, ale co i raz pojawiają się kolejne pytania dotyczące tego systemu. Mam nieodparte wrażenie, że prace postępują dość chaotycznie. To bardzo źle - z punktu widzenia bazy danych. Proszę się poważnie zastanowić, bo jak kolega zauważył - później zmiany będą bardzo trudne. Chodzi mi głównie o stronę organizacyjną przedsięwzięcia. Baza danych, to takie miejsce, które dostaje po tyłku jak coś się w systemie zmienia - gdziekolwiek. Wniosek jest taki, że zmian należy unikać. A jak już się je robi - warto mieć to sensownie przygotowane.
Link do wypowiedziLink
Michał Płonka

Michał Płonka Programista PHP

Temat: [PostgreSQL] Indeks daty - timestamp vs date

Dziękuję wszystkim za wypowiedzi, nawet te nieco "złośliwe". Cały schemat bazy danych został (moim zdaniem) dobrze przemyślany, na chwilę obecną nie ma żadnych problemów z wydajnością. Swoje pytanie zadałem tylko i wyłącznie po to by dowiedzieć się, czy takowa zmiana ma faktycznie sens.

Szczerze mówiąc domyślałem się, że:
'2009-12-12'::date == '2009-12-12 00:00:00'::datetime (+ ileśtam miejsc po przecinku )
ale jednak wolałem się upewnić. W takim przypadku faktycznie zmiana typu pola nie odegrałaby większego znaczenia. O to mi właśnie chodziło.

Czy prace postępują chaotycznie? Nie. To, że pozwalam sobie zadawać pytania wcale o tym nie świadczy. Wychodząc z takiego założenia to każdy, kto zadaje pytania, pracuje nad "chaotycznym" projektem.
Link do wypowiedziLink

konto usunięte

Temat: [PostgreSQL] Indeks daty - timestamp vs date

Szczerze mówiąc to polecam jednak stosowanie zwykłego pola "date".
Bardzo to ułatwia oprogramowywanie pola, a np. w polach typu "data zakupu" czas nie ma żadnego znaczenia (w odróżnieniu od "data i czas transakcji").
Link do wypowiedziLink
Jakub L.

Jakub L. Programista

Temat: [PostgreSQL] Indeks daty - timestamp vs date

A nie możecie zrobić 2 instancji bazy rózniące się tylko tą jedną kolumną, nawsadzać tam ile rekordów przewidujecie plus jeszcze trochę i użyć explain analyze?
Link do wypowiedziLink

konto usunięte

Temat: [PostgreSQL] Indeks daty - timestamp vs date

Jakub L.:
A nie możecie zrobić 2 instancji bazy rózniące się tylko tą jedną kolumną, nawsadzać tam ile rekordów przewidujecie plus jeszcze trochę i użyć explain analyze?

to jest naprawdę głupi pomysł

przy dużej ilości danych ewentualny rozjazd to jakaś masakra przy przywracaniu do stanu uzywalności
Link do wypowiedziLink
Jakub L.

Jakub L. Programista

Temat: [PostgreSQL] Indeks daty - timestamp vs date

Przemysław R.:
Jakub L.:
A nie możecie zrobić 2 instancji bazy rózniące się tylko tą jedną kolumną, nawsadzać tam ile rekordów przewidujecie plus jeszcze trochę i użyć explain analyze?

to jest naprawdę głupi pomysł

przy dużej ilości danych ewentualny rozjazd to jakaś masakra przy przywracaniu do stanu uzywalności

Nie mówię, żeby to było na produkcję, tylko do testów.
Zrobić bazy, nawrzucać danych testowych (skryptem) i puścić kilka selectów z analizą.
Kto wie, co jeszce wyskoczy przy czymś takim, lepiej teraz niż po wdrożeniu.
Link do wypowiedziLink

konto usunięte

Temat: [PostgreSQL] Indeks daty - timestamp vs date

Michał Płonka:
Witam,
w tabeli w bazie PostgreSQL mam pole typu TIMESTAMP WITHOUT TIME ZONE. Generalnie nie potrzebuję w nim dokładności większej niż dzień więc w zupełności wystarczyłoby mi pole typu DATE. Przezornie jednak na razie zostawiłem jak jest.
Pytanie moje jest następujące: wyszukiwanie po tym polu odbywa się tylko i wyłącznie w "ramach" dni (czyli WHERE pole >= '2009-12-22') bez patrzenia na czas. To samo tyczy się grupowania: grupuję dane dla danych dni. Na polu tym mam założony indeks, który generalnie sprawdza się nieźle. Czy (biorąc pod uwagę brak znaczenia czasu z pola) lepszym wyjściem byłoby przerobienie pola na typ DATE? Jak to będzie wyglądało dla indeksu?
Czyli reasumując: czy odczuję jakąś większą korzyść podczas wyszukiwania po zmianie pola na typ DATE?

PS: Dodam, że zależy mi na jak najlepszej wydajności bazy. Dzienny przyrost bazy to ok. 500MB więc z każdym dniem kolejne modyfikacje będą trudniejsze.Michał Płonka edytował(a) ten post dnia 22.12.09 o godzinie 19:06

jak chcesz wydajnie to zrób częściową denormalizację - czyli dwa pola jedno z datą drugie z datą i godziną indeks załóż na to pole które będzie filtowane lub wykorzystane w jakiś tam zapytaniach

dane w dodatkowej kolumnie aktualizuj w momencie modyfikacji danych -> trigger np albo z poziomu zapytania modyfikującego

zresztą trzeba by było wykonać plan wykonania i dopiero na tej podstawie optymalizować
Link do wypowiedziLink

konto usunięte

Temat: [PostgreSQL] Indeks daty - timestamp vs date

Jakub L.:
Nie mówię, żeby to było na produkcję, tylko do testów.
Zrobić bazy, nawrzucać danych testowych (skryptem) i puścić kilka selectów z analizą.
Kto wie, co jeszce wyskoczy przy czymś takim, lepiej teraz niż po wdrożeniu.

a chyba że do tego, to jest ok
Link do wypowiedziLink
Michał Płonka

Michał Płonka Programista PHP

Temat: [PostgreSQL] Indeks daty - timestamp vs date

Chyba faktycznie zrobię testy empiryczne. Utworzę kopię tabeli z innym typem pola i zobaczę jak będzie wykonywane zapytanie. Jeżeli jednak '2009-12-12'::date == '2009-12-12 00:00:00'::datetime to teoretycznie nie powinienem odczuć żadnej różnicy.
Link do wypowiedziLink
Przemysław Krygier

Przemysław Krygier Specjalista Systemów
Informatycznych

Temat: [PostgreSQL] Indeks daty - timestamp vs date

Przemysław R.:
Jakub L.:
A nie możecie zrobić 2 instancji bazy rózniące się tylko tą jedną kolumną, nawsadzać tam ile rekordów przewidujecie plus jeszcze trochę i użyć explain analyze?

to jest naprawdę głupi pomysł

przy dużej ilości danych ewentualny rozjazd to jakaś masakra przy przywracaniu do stanu uzywalności


Cóż ... Przemek ... pomijając merytorykę ...wyrażenie

to jest naprawdę głupi pomysł

jest delikatnie mówiąc pozbawione klasy ... i żałuję, że nie mogę wręczyć minusa. Fora dyskusyjne służą do DYSKUTOWANIA i dzielenia się wiedzą ... dla mnie pomysł Jakuba też nie jest trafiony, ale !!! ... wyłóż to poprzez argumenty.

Dbajmy o kulturę - bo nikt za nas tego nie zrobi.

Pozdrawiam
Link do wypowiedziLink

konto usunięte

Temat: [PostgreSQL] Indeks daty - timestamp vs date

Przemysław Krygier:

Cóż ... Przemek ... pomijając merytorykę ...wyrażenie

to jest naprawdę głupi pomysł

jest delikatnie mówiąc pozbawione klasy ... i żałuję, że nie mogę wręczyć minusa. Fora dyskusyjne służą do DYSKUTOWANIA i dzielenia się wiedzą ... dla mnie pomysł Jakuba też nie jest trafiony, ale !!! ... wyłóż to poprzez argumenty.

Dbajmy o kulturę - bo nikt za nas tego nie zrobi.

Pozdrawiam

mogłem użyć innego bardziej zgrabnego słowa, cóż wpadka
Link do wypowiedziLink
Michał Płonka

Michał Płonka Programista PHP

Temat: [PostgreSQL] Indeks daty - timestamp vs date

Hmmm, nie wiem z czego Przemysław Krygier robi problem: przecież nikt nie obraził żadnego użytkownika; wyrażona została opinia na temat pomysłu. Przymiotnik nie odnosi się więc do użytkownika jako osoby tylko do zasugerowanego rozwiązania.

PS: sprawdziłem empirycznie i nie ma żadnych różnic w czasach ani w planach wykonania zapytania. Jedyne więc co tracę to 4 bajty dla każdego rekordu co przy 500000 rekordów dziennie daje 0.5MB utraty danych (a dzienny przyrost to 500MB). Chyba więc pozostawię TIMESTAMP - może się w przyszłości okazać, że czas będzie jednak przydatny. Dziękuję wszystkim za udział w dyskusji.Michał Płonka edytował(a) ten post dnia 23.12.09 o godzinie 17:19
Link do wypowiedziLink

konto usunięte

Temat: [PostgreSQL] Indeks daty - timestamp vs date

Michał Płonka:
PS: sprawdziłem empirycznie i nie ma żadnych różnic w czasach ani w planach wykonania zapytania. Jedyne więc co tracę to 4 bajty dla każdego rekordu co przy 500000 rekordów dziennie daje 0.5MB utraty danych (a dzienny przyrost to 500MB). Chyba więc pozostawię TIMESTAMP - może się w przyszłości okazać, że czas będzie jednak przydatny. Dziękuję wszystkim za udział w dyskusji.

Nie znam aż tak PostgreSQL, ale zdradź może jak porównasz dwie daty czy są takie same, ignorując (odrzucając) przy tym czas, oczywiście przy użyciu indeksu?Piotr Likus edytował(a) ten post dnia 23.12.09 o godzinie 22:18
Link do wypowiedziLink

konto usunięte

Temat: [PostgreSQL] Indeks daty - timestamp vs date

Piotr Likus:
Michał Płonka:
PS: sprawdziłem empirycznie i nie ma żadnych różnic w czasach ani w planach wykonania zapytania. Jedyne więc co tracę to 4 bajty dla każdego rekordu co przy 500000 rekordów dziennie daje 0.5MB utraty danych (a dzienny przyrost to 500MB). Chyba więc pozostawię TIMESTAMP - może się w przyszłości okazać, że czas będzie jednak przydatny. Dziękuję wszystkim za udział w dyskusji.

Nie znam aż tak PostgreSQL, ale zdradź może jak porównasz dwie daty czy są takie same, ignorując (odrzucając) przy tym czas, oczywiście przy użyciu indeksu?Piotr Likus edytował(a) ten post dnia 23.12.09 o godzinie 22:18


where data_1::date = '2009-01-01'::date
a do tego indeks: create index i_date on tabela(data_1::date);

i powinno używać indeksu :)
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Pgsql przyspieszanie count ...




Wyślij zaproszenie do
Anuluj