ďťż
 
[POSTGRESQL] Optymalizacja bazy danych ďťż
 
[POSTGRESQL] Optymalizacja bazy danych
Zobacz wiadomości
 
Cytat
A gdyby tak się wedrzeć na umysłów górę, / Gdyby stanąć na ludzkich myśli piramidzie, / I przebić czołem przesądów chmurę, / I być najwyższą myślą wcieloną. . . Juliusz Słowacki, Kordian
Indeks BCB i MySQL subiekt gt fototapeta
 
  Witamy

[POSTGRESQL] Optymalizacja bazy danych



Piotr Gasidlo - 24-10-2007 00:01
[POSTGRESQL] Optymalizacja bazy danych
  Witam,

Może temat ogólny, ale zaraz wyjasniam.

Mam tabelkę, zawierająca 150k danych.

Tabelka postaci:

create table objects(
id serial,
... -- rozne dane
usage bigint not null default 0,
check_usage_date timestamp not null default now()
)

PRIMARY KEY to id. Na tabelce jest jeszcze kilka indeksów (głównie
warunkowych). Tabelka zawiera pola varchar (bez okreslenia rozmiaru).

Co pewien czas (średnio co 2h) wszystkie rekordy mają atkualizowane pola
usage i check_usage_date, tj.

UPDATE objects SET usage = ?, check_usage_date = NOW() WHERE id = ?

Pytanie:
Czy przeniesienie kolumn usage i check_usage_date do osobnej tabeli, tj.

create table objects_usage(
object_id integer not null,
usage bigint not null default 0,
check_usage_date timestamp not null default now()
);

poprawi ogólną wydajność bazy danych (na tabeli jest wykonywanych dużo
SELECtów).

Czy UPDATowanie wierszy powoduje, że PostgreSQL fizycznie musi dokonać
kopiowania wszystkich wartości z wiersza do nowej fizycznej lokalizacji
i uaktualnienia wszystkich indeksów czy tez, dla powyższych typów
(bigint, timestamp) zmieniany jest tylko konkretny wiersz i nie
występuje koniecznośc uaktualnienia indeksów?

Korzystam z PostgreSQL 8.1.

--
Piotr 'QuakeR' Gasidło, BOFH @ pandora.barbara.eu.org
############## sending lusers to /dev/null since 1998
##### Waiting for tomorrow, for a little ray of light
### Waiting for tomorrow just to see your smile again





hubert depesz lubaczewski - 24-10-2007 00:01

  Dnia 23.10.2007 Piotr Gasidlo <quaker@pandora.barbara.eu.org> napisał/a:
> Czy przeniesienie kolumn usage i check_usage_date do osobnej tabeli, tj.
> poprawi ogólną wydajność bazy danych (na tabeli jest wykonywanych dużo
> SELECtów).

tak.

> Czy UPDATowanie wierszy powoduje, że PostgreSQL fizycznie musi dokonać
> kopiowania wszystkich wartości z wiersza do nowej fizycznej lokalizacji
> i uaktualnienia wszystkich indeksów czy tez, dla powyższych typów
> (bigint, timestamp) zmieniany jest tylko konkretny wiersz i nie
> występuje koniecznośc uaktualnienia indeksów?

a to już drugie pytanie. odpowiedź: wszystkie pola, wszystkie indeksy.

depesz

--
quicksil1er: "postgres is excellent, but like any DB it requires a
highly paid DBA. here's my CV!" :)
http://www.depesz.com/ - blog dla ciebie (i moje CV)




Piotr Gasidlo - 25-10-2007 00:02

  On 2007-10-23, hubert depesz lubaczewski <depesz@depesz.com> wrote:
> Dnia 23.10.2007 Piotr Gasidlo <quaker@pandora.barbara.eu.org> napisał/a:
>> Czy przeniesienie kolumn usage i check_usage_date do osobnej tabeli, tj.
>> poprawi ogólną wydajność bazy danych (na tabeli jest wykonywanych dużo
>> SELECtów).
>
> tak.

Faktycznie. Wygląda, że po poprawkach obciążenie serwera spadło dość
znacznie.

>> Czy UPDATowanie wierszy powoduje, że PostgreSQL fizycznie musi dokonać
>> kopiowania wszystkich wartości z wiersza do nowej fizycznej lokalizacji
>> i uaktualnienia wszystkich indeksów czy tez, dla powyższych typów
>> (bigint, timestamp) zmieniany jest tylko konkretny wiersz i nie
>> występuje koniecznośc uaktualnienia indeksów?
>
> a to już drugie pytanie. odpowiedź: wszystkie pola, wszystkie indeksy.

Dzięki.

--
Piotr 'QuakeR' Gasidło, BOFH @ pandora.barbara.eu.org
############## sending lusers to /dev/null since 1998
##### Waiting for tomorrow, for a little ray of light
### Waiting for tomorrow just to see your smile again
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • effulla.pev.pl
  • comp
    [PostgreSQL] - jak =?ISO-8859-2?Q?zabezpieczy=E6_interesy_tw?==?ISO-8859-2?Q?=F3rcy_systemu_=3F=3F=3F?= postgresql - int/int [MSSQL2000] Problem z =?ISO-8859-2?Q?tabel=B1/indeksem/zapytanie?==?ISO-8859-2?Q?m_czy_b=B3=B1d_w_bazie_danych=2E=2E=2E?= postgresql Select count(*) czy raczej Select count(ID) [PostgreSQL] jak =?ISO-8859-2?Q?pobra=E6_warto=B6=E6_zwracan?==?ISO-8859-2?Q?=B1_przez_funkcj=EA=3F?= [postgresql] INSERT OR UPDATE - jak =?ISO-8859-2?Q?b=EAdzie_na?==?ISO-8859-2?Q?jlepiej=3F?= [postgresql] kilka =?ISO-8859-2?Q?rekord=F3w_subquery_jako_?==?ISO-8859-2?Q?string?= [PostgreSQL] Jak =?ISO-8859-2?Q?po=B3=B1czy=E6_funkcje_z_w?==?ISO-8859-2?Q?idokiem?= Postgres - replikcja master-master Dopasowanie do "najlepszego" dopasowania :) [ PostgreSQL]
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • oefg.opx.pl
  • Cytat

    Decede mihi sole - nie zasłaniaj mi słonca.
    Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
    Hoc fac - tak czyń.
    A tergo - od tyłu; z tyłu.
    I czarne włosy posiwieją. Safona

    Valid HTML 4.01 Transitional

    Free website template provided by freeweblooks.com