Re: limiting hint bit I/O

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: limiting hint bit I/O
Дата
Msg-id 4DA1459D-D290-4C78-988D-6312B1C0F677@nasby.net
обсуждение исходный текст
Ответ на Re: limiting hint bit I/O  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
On Jan 14, 2011, at 7:24 PM, Josh Berkus wrote:
> On 1/14/11 11:51 AM, Tom Lane wrote:
>> The people whose tables are mostly insert-only complain about it, but
>> that's not the majority of our userbase IMO.  We just happen to have a
>> couple of particularly vocal ones, like Berkus.
>
> It might or might not be the majority, but it's an extremely common case
> affecting a lot of users.  Many, if not most, software applications have
> a "log" table (or two, or three) which just accumulates rows, and when
> that log table gets a vacuum freeze it pretty much halts the database in
> its tracks.  Between my client practice and IRC, I run across complaints
> about this issue around 3 times a month.
>
> And data warehousing is a significant portion of our user base, and
> *all* DW users are affected by this.  In some cases, vacuum issues are
> sufficient to prevent people from using PostgreSQL for data warehousing.

This also affects us every time we stand up a new londiste replica, and I expect Slony folks would suffer the same
thing.When you copy everything over, that's going to happen in a relatively short range of XIDs, so when those XIDs
starthitting freeze age suddenly *everything* needs to get frozen. 

As for hint bits, you're generally not going to have anyone reading from a slave that's still being built, so you won't
seeany hint bit setting until you actually open up for users. So for the first X amount of time, performance takes a
bighit because you have to write all the hints out. Granted, you can technically VACUUM FREEZE after the slave is
built,but that means more time before you can start using the slave and it's something you have to remember to do. 
--
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net




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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: We need to log aborted autovacuums
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: texteq/byteaeq: avoid detoast [REVIEW]