Re: Table and Index compression
От | Kevin Grittner |
---|---|
Тема | Re: Table and Index compression |
Дата | |
Msg-id | 4A7BE8FB0200002500029648@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: Table and Index compression (Pierre Frédéric Caillaud<lists@peufeu.com>) |
Ответы |
Re: Table and Index compression
|
Список | 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 по дате отправления: