From: | Rauan Maemirov <rauan(at)maemirov(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL 8.4 performance tuning questions |
Date: | 2009-07-30 22:02:45 |
Message-ID: | c78bcec0907301502t3aec056cj9abd4894a711f78@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hey guyz, thanks for help. I solved the problems. The reason was in
bad query, that i've accidentally committed right after upgrading.
PostgreSQL 8.4 is perfect! Analyze works like a charm, and MUCH better
than in 8.3.
2009/7/31 Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Scott Carey <scott(at)richrelevance(dot)com> writes:
>>> Gzip does have some quirky performance behavior depending on the
>>> chunk size of data you stream into it.
>>
>> Can you enlarge on that comment? I'm not sure that pg_dump is aware
>> that there's anything to worry about there.
>
> If the library used here is anything like the native library used by
> Java, it'd be worth putting a buffer layer ahead of the calls to gzip,
> so it isn't dealing with each individual value as a separate call. I
> seem to remember running into that issue in Java, where throwing a
> BufferedOutputStream in there fixed the performance issue.
>
> -Kevin
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Carey | 2009-07-30 22:07:42 | Re: PostgreSQL 8.4 performance tuning questions |
Previous Message | Kevin Grittner | 2009-07-30 22:00:00 | Re: PostgreSQL 8.4 performance tuning questions |