Re: Further pg_upgrade analysis for many tables

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Further pg_upgrade analysis for many tables
Дата
Msg-id 509BEC23.90203@eisentraut.org
обсуждение исходный текст
Ответ на Further pg_upgrade analysis for many tables  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Further pg_upgrade analysis for many tables  (Bruce Momjian <bruce@momjian.us>)
Re: Further pg_upgrade analysis for many tables  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On 11/7/12 9:17 PM, Bruce Momjian wrote:
> As a followup to Magnus's report that pg_upgrade was slow for many
> tables, I did some more testing with many tables, e.g.:
> 
>     CREATE TABLE test991 (x SERIAL);
> 
> I ran it for 0, 1k, 2k, ... 16k tables, and got these results:
> 
>     tables    pg_dump     restore     pg_upgrade(increase)
>         0       0.30        0.24       11.73(-)
>      1000       6.46        6.55       28.79(2.45x)
>      2000      29.82       20.96       69.75(2.42x)
>      4000      95.70      115.88      289.82(4.16x)
>      8000     405.38      505.93     1168.60(4.03x)
>     16000    1702.23     2197.56     5022.82(4.30x)

I can reproduce these numbers, more or less.  (Additionally, it ran out
of shared memory with the default setting when dumping the 8000 tables.)

But this issue seems to be entirely the fault of sequences being
present.  When I replace the serial column with an int, everything
finishes within seconds and scales seemingly linearly.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Proof of concept: auto updatable views [Review of Patch]
Следующее
От: Amit kapila
Дата:
Сообщение: Re: Performance Improvement by reducing WAL for Update Operation