| From: | Scott Carey <scott(at)richrelevance(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Matthew Wakeling <matthew(at)flymine(dot)org>, "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:07:42 |
| Message-ID: | C69767BE.DDB4%scott@richrelevance.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 7/30/09 2:53 PM, "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.
>
> regards, tom lane
>
For example, one of the things that gzip does is calculate the crc of the
item being compressed. Calculating that incrementally is less efficient
than doing it in bulk.
For whatever reason, some other internals of gzip tend to perform much
better if submitting say, 4k or 8k or 16k chunks rather than little bits at
a time. But I'm sure some of that also depends on what library you're using
since they all vary somewhat.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-07-30 22:30:20 | Re: PostgreSQL 8.4 performance tuning questions |
| Previous Message | Rauan Maemirov | 2009-07-30 22:02:45 | Re: PostgreSQL 8.4 performance tuning questions |