Re: logical changeset generation v6.2

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: logical changeset generation v6.2
Дата
Msg-id 20131014210750.GD25013@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: logical changeset generation v6.2  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: logical changeset generation v6.2  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 2013-10-14 15:51:14 +0200, Andres Freund wrote:
> > > It'd probably not hurt to redo those benchmarks to make sure...
> >
> > Yes, I think it would be good to characterize it more precisely than
> > "a bit", so people know what to expect.
>
> A "bit" was below the 3% range for loops of adding columns.
>
> So, any tests you'd like to see?
> * loop around CREATE TABLE/DROP TABLE
> * loop around ALTER TABLE ... ADD COLUMN
> * loop around CREATE FUNCTION/DROP FUNCTION

So, see the attatched benchmark skript. I've always done using a disk
bound and a memory bound (using eatmydata, preventing fsyncs) run.

* unpatched run, wal_level = hot_standby, eatmydata
* unpatched run, wal_level = hot_standby

* patched run, wal_level = hot_standby, eatmydata
* patched run, wal_level = hot_standby

* patched run, wal_level = logical, eatmydata
* patched run, wal_level = logical

Based on those results, there's no difference above noise for
wal_level=hot_standby, with or without the patch. With wal_level=logical
there's a measurable increase in wal traffic (~12-17%), but no
performance decrease above noise.

>From my POV that's ok, those are really crazy catalog workloads.

Greetings,

Andres Freund

--
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Вложения

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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [PATCH] Add use of asprintf()
Следующее
От: Kohei KaiGai
Дата:
Сообщение: Re: Triggers on foreign tables