Re: Concurrent HOT Update interference

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Concurrent HOT Update interference
Дата
Msg-id CA+U5nMJRBy+ad1f7J1x8A07hg--yEDEGkBNrLfXdvjSD0_K7jg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Concurrent HOT Update interference  (Greg Stark <stark@mit.edu>)
Список pgsql-hackers
On 10 May 2013 15:47, Greg Stark <stark@mit.edu> wrote:
> On Fri, May 10, 2013 at 3:04 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> a) Updating two separate rows that happen to be on the same block will
>> eventually cause one or both of the rows to migrate to separate blocks
>> because of 1) the inability to clean the existing block and 2) the way
>> our fsm algorithm gives you a clean new block away from other people.
>> That leads to a one-block-per-row situation, or in other words quite
>> bad bloating, which seems to be avoidable, hence this thread.
>
> This seems like a good behaviour to me. If you have N busy rows then
> having each row in its own block minimizes contention and minimizes
> the frequency of cleanups. You can't be both worried about bloating
> *and* contention -- either you have relatively few busy rows per
> processor in which case the bloat is minor and the contention is an
> issue or you have many rows in which case the contention can't be an
> issue and the bloat becomes important.

For very small tables, yes, for anything else, no.

Bloat and contention both slow you down. Difference is that bloat
slows other people down as well by filling up RAM and causing extra
I/O.

If you have roving contention your table quickly spreads out to one
table per block, which ain't great.

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



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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Concurrent HOT Update interference
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] Make "psql -1 < file.sql" work as with "-f"