Re: Table and Index compression - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Table and Index compression
Date
Msg-id 4A7BE8FB0200002500029648@gw.wicourts.gov
Whole thread Raw
In response to Re: Table and Index compression  (Pierre Frédéric Caillaud<lists@peufeu.com>)
Responses Re: Table and Index compression  (Pierre Frédéric Caillaud<lists@peufeu.com>)
List pgsql-hackers
Pierre Frédéric Caillaud<lists@peufeu.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


pgsql-hackers by date:

Previous
From: Zdenek Kotala
Date:
Subject: Re: compilation with libeditpreferred is broken
Next
From: Peter Eisentraut
Date:
Subject: ALTER TABLE SET STATISTICS requires AccessExclusiveLock