Re: Table and Index compression

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Greg Stark" <gsstark(at)mit(dot)edu>, Pierre Frédéric Caillaud <lists(at)peufeu(dot)com>, "Sam Mason" <sam(at)samason(dot)me(dot)uk>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Table and Index compression
Date: 2009-08-07 13:42:35
Message-ID: 4A7BE8FB0200002500029648@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pierre Frédéric Caillaud<lists(at)peufeu(dot)com> wrote:

> tablespace is a RAID5 of 3 drives, xlog in on a RAID1 of 2 drives,
> but it does it too if I put the tablespace and data on the same
> volume.

> it starts out relatively fast :
>
> si so bi bo in cs us sy id wa
> 0 0 0 43680 2796 19162 42 18 37 3
> 0 0 0 45515 3165 20652 44 17 35 4
> 0 0 0 43130 3046 21991 43 17 38 2
>
> then here it starts to slow down : check "bo" output
>
> 0 0 181 24439 577 3541 31 6 40 23
> 0 0 176 17258 292 1324 31 4 43 22
> 0 0 0 18626 162 693 35 3 49 12
> 0 0 1 21554 235 1362 31 5 50 14
> 0 0 0 19177 324 2053 35 4 50 12
> 0 0 0 19208 206 1155 36 4 48 12
> 0 0 1 20740 215 1117 33 4 50 13
> 0 0 0 20154 258 1100 32 4 50 14
> 0 0 0 20355 316 2056 34 5 49 12
>
> ... and it stays like this until the end of the INSERT...

I don't know if this is it, but we tend to see outrageously high
performance at the start of a benchmark because of the battery-backed
cache in the RAID controller. Every write comes back immediately
after copying the data to RAM. After a while the cache gets filled
and you settle down to a steady state. If it's not BBU with
write-back enabled, perhaps you have drives that lie about write
completion?

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2009-08-07 13:58:42 ALTER TABLE SET STATISTICS requires AccessExclusiveLock
Previous Message Zdenek Kotala 2009-08-07 13:41:09 Re: compilation with libeditpreferred is broken