ďťż
 
Postgresql 8.1 =?ISO-8859-2?Q?-osi=B1gi_=3F?= ďťż
 
Postgresql 8.1 =?ISO-8859-2?Q?-osi=B1gi_=3F?=
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 8.1 =?ISO-8859-2?Q?-osi=B1gi_=3F?=



Janusz - 13-03-2006 11:21
Postgresql 8.1 =?ISO-8859-2?Q?-osi=B1gi_=3F?=
  Witajcie

jest tak: miałem Postgresql 7.4 na którym ustawiłem bazę na której wykonuję zapytania z wykorzystaniem funkcji w plpgsql zwracających tabelę (returns setof record), dużo sumowań itd.
Zachciało mi się Postgresa 8.1 no bo niby taki wypasiony. Zainstalowałem go i raporty które poprzednio leciały w 15 sekund teraz robią sie - dosłownie !* - 30 minut* !
.... no żesz qr...czę ale wypas :[
baza odtworzona została z normalnego dumpa. Przeładowałem dane i zrobiłem vaccum analyze full. I nic.
W systemie nic nie zmieniałem poza instalacja wersji 8.1 - juz poprzednio, przy 7.4 zrobiłem tuning* przydziału pamięci.

Macie pomysł na to co mu jest ?

system:
Debian Sarge, P4 3.0 HT, 1GB RAM, jądro 2.6.8-2-686-smp
Postgres 7.4 był z dystrybucji stable
Postgres 8.1 z testinga

Pozdrawiam
Janusz





Artur Muszynski - 13-03-2006 11:21
=?iso-8859-2?Q?Re:_Postgresql_8.1_-osi=B1gi_=3F?=
 
"Janusz" <johnrut-to_usun-@klienci.pkobp.pl> wrote in message news:du9180$tfp$1@news.onet.pl...
> Witajcie
>
> jest tak: miałem Postgresql 7.4 na którym ustawiłem bazę na której wykonuję zapytania z wykorzystaniem funkcji w plpgsql zwracających tabelę (returns setof record), dużo sumowań itd.
> Zachciało mi się Postgresa 8.1 no bo niby taki wypasiony. Zainstalowałem go i raporty które poprzednio leciały w 15 sekund teraz robią sie - dosłownie ! - 30 minut !
> ... no żesz qr...czę ale wypas :[
> baza odtworzona została z normalnego dumpa. Przeładowałem dane i zrobiłem vaccum analyze full. I nic.
> W systemie nic nie zmieniałem poza instalacja wersji 8.1 - juz poprzednio, przy 7.4 zrobiłem tuning przydziału pamięci.
>
> Macie pomysł na to co mu jest ?

Możesz włączyć log zapytań (powiedzmy przekraczających x sekund, żeby było mniej do analizy) i spróbować przyjrzeć się bliżej problemowi.

artur




Robert Grabowski - 13-03-2006 11:21

  Janusz wrote:
> Witajcie
>
> jest tak: miałem Postgresql 7.4 na którym ustawiłem bazę na której
> wykonuję zapytania z wykorzystaniem funkcji w plpgsql zwracających
> tabelę (returns setof record), dużo sumowań itd.
> Zachciało mi się Postgresa 8.1 no bo niby taki wypasiony. Zainstalowałem
> go i raporty które poprzednio leciały w 15 sekund teraz robią sie-
> dosłownie ! - 30 minut !
> ... no żesz qr...czę ale wypas :[
> baza odtworzona została z normalnego dumpa. Przeładowałem dane i
> zrobiłem vaccum analyze full. I nic.
> W systemie nic nie zmieniałem poza instalacja wersji 8.1 - juz
> poprzednio, przy 7.4 zrobiłem tuning przydziału pamięci.
>
> Macie pomysł na to co mu jest ?
>

Czy w funkcji jest duże zapytanie?

1. Pokaż plan tego zapytania?
2. Spróbuj zmienić funkcję, aby w niej zapytanie było wywoływane przez
EXECUTE ...

pozdrawiam
Robert Grabowski




=?ISO-8859-2?Q?Pawe=B3_Matejski?= - 13-03-2006 11:21

  Robert Grabowski wrote:
> Janusz wrote:
>
>>Witajcie
>>
>>jest tak: miałem Postgresql 7.4 na którym ustawiłem bazę na której
>>wykonuję zapytania z wykorzystaniem funkcji w plpgsql zwracających
>>tabelę (returns setof record), dużo sumowań itd.
>>Zachciało mi się Postgresa 8.1 no bo niby taki wypasiony. Zainstalowałem
>>go i raporty które poprzednio leciały w 15 sekund teraz robią sie -
>>dosłownie ! - 30 minut !
>>... no żesz qr...czę ale wypas :[
>>baza odtworzona została z normalnego dumpa. Przeładowałem dane i
>>zrobiłem vaccum analyze full. I nic.
>>W systemie nic nie zmieniałem poza instalacja wersji 8.1 - juz
>>poprzednio, przy 7.4 zrobiłem tuning przydziału pamięci.
>>
>>Macie pomysł na to co mu jest ?
>>
>
>
> Czy w funkcji jest duże zapytanie?
>
> 1. Pokaż plan tego zapytania?
> 2. Spróbuj zmienić funkcję, aby w niej zapytanie było wywoływane przez
> EXECUTE ...

A czemu to ostatnie miałoby pomóc? Funkcja jest parsowana tylko podczas
pierwszego użycia w danej sesji (a wiec zapytanie w jej kodzie), a zapytanie
w EXECUTE będzie preparowane za każdym razem. Jeśli to będzie jeszcze w jakiejś
pętli...
Oczywiście w pewnych szczególnych przypadkach pomoże, ale przedpiśca nie dał szczegółowych
informacji. :)

--
P.M.





Robert Grabowski - 13-03-2006 11:21

  Paweł Matejski wrote:
> Robert Grabowski wrote:
>> Janusz wrote:
>>
>>> Witajcie
>>>
>>> jest tak: miałem Postgresql 7.4 na którym ustawiłem bazę na której
>>> wykonuję zapytania z wykorzystaniem funkcji w plpgsql zwracających
>>> tabelę (returns setof record), dużo sumowań itd.
>>> Zachciało mi się Postgresa 8.1 no bo niby taki wypasiony. Zainstalowałem
>>> go i raporty które poprzednio leciały w 15 sekund teraz robią sie -
>>> dosłownie ! - 30 minut !
>>> ... no żesz qr...czę ale wypas :[
>>> baza odtworzona została z normalnego dumpa. Przeładowałem dane i
>>> zrobiłem vaccum analyze full. I nic.
>>> W systemie nic nie zmieniałem poza instalacja wersji 8.1 - juz
>>> poprzednio, przy 7.4 zrobiłem tuning przydziału pamięci.
>>>
>>> Macie pomysł na to co mu jest ?
>>>
>>
>>
>> Czy w funkcji jest duże zapytanie?
>>
>> 1. Pokaż plan tego zapytania?
>> 2. Spróbuj zmienić funkcję, aby w niej zapytanie było wywoływane przez
>> EXECUTE ...
>
> A czemu to ostatnie miałoby pomóc? Funkcja jest parsowana tylko podczas
> pierwszego użycia w danej sesji (a wiec zapytanie w jej kodzie), a
> zapytanie
> w EXECUTE będzie preparowane za każdym razem. Jeśli to będzie jeszcze w
> jakiejś
> pętli...
> Oczywiście w pewnych szczególnych przypadkach pomoże, ale przedpiśca nie
> dał szczegółowych
> informacji. :)
>

Może pomóć, bo optymalizator będzie za każdym razem wyznaczałplan. Do
wyznaczania planu brane są też wartości przy warunkach, np. dla dat.
Jeżeli zapytanie wygląda tak:

select * from raport where date between ? and ?

to jeżeli dla pierwszego wywołania może być skostruowany plan z seqscan
(bo taki będzie zares dat), to kolejne wywołania również będzierównież
seqscan, mimo, że za drugim i kolejnym wywołaniem zakres dat może być
już na tyle wąski, że indexscan byłby zdecydowanie szybszy.

pozdrawiam
Robert Grabowski
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • effulla.pev.pl
  • comp
    Wydajność baz danych w zależności od poziomu izolacji ANSI/ISO Czy zna (obsługuje) ktoś program Iso Draw ? MYSQL - kodowanie w ISO-PL strona plus baza w iso do utf-8 Kodowanie: z iso na utf postgresql - int/int postgresql Select count(*) czy raczej Select count(ID) Postgres - replikcja master-master Dopasowanie do "najlepszego" dopasowania :) [ PostgreSQL] Jak =?windows-1250?Q?pobra=E6_szacowan=B9_wielko=9C=E6_zbiory_wy nikowego_w_MS?==?windows-1250?Q?_SQL_2005=3F?=
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • atanvarne633.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