Re: increasing the default WAL segment size

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: increasing the default WAL segment size
Дата
Msg-id CA+TgmoY0HBZhex0jsXgnDuCNDKdP10bRnGzWyas73EOXeJjb5A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: increasing the default WAL segment size  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: increasing the default WAL segment size  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On Thu, Aug 25, 2016 at 9:48 AM, Stephen Frost <sfrost@snowman.net> wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> Meanwhile, we'll significantly help people who are currently
>> generating painfully large but not totally insane numbers of WAL
>> segments.  Someone who is currently generating 32,768 WAL segments per
>> day - about one every 2.6 seconds - will have a significantly easier
>> time if they start generating 8,192 WAL segments per day - about one
>> every 10.5 seconds - instead.  It's just much easier for a reasonably
>> simple archive command to keep up, "ls" doesn't have as many directory
>> entries to sort, etc.
>
> I'm generally on-board with increasing the WAL segment size, and I can
> see the point that we might want to make it more easily configurable as
> it's valuable to set it differently on a small database vs. a large
> database, but I take exception with the notion that a "simple archive
> command" is ever appropriate.

My point wasn't really that archive_command should actually be simple.
My point was that if it's being run multiple times per second, there
are additional challenges that wouldn't arise if it were being run
only every 5-10 seconds.

I guess I should have said "simpler" rather than "reasonably simple",
because there's nothing simple about setting archive_command properly.
I mean, it could only actually be simple if somebody had a good a
backup tool that provided an archive_command that you could just drop
in place.  But I'm sure if somebody had such a tool, they'd take every
opportunity to bring it up, so we doubtless would have heard about it
by now.  Right?  :-)

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Ivan Frolkov
Дата:
Сообщение: UPSERT strange behavior
Следующее
От: Yury Zhuravlev
Дата:
Сообщение: Why is a newly created index contains the invalidLSN?