Re: Table and Index compression

On Fri, 07 Aug 2009 15:42:35 +0200, Kevin Grittner  
<Kevin.Grittner@wicourts.gov> wrote:

> 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
>

I'm answering my own question : at the beginning of the run, postgres  
creates a 800MB temporary file, then it fills the table, then deletes the  
temp file.
Is this because I use generate_series to fill the test table ?