Re: limiting hint bit I/O - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: limiting hint bit I/O
Date
Msg-id 4DA1459D-D290-4C78-988D-6312B1C0F677@nasby.net
Whole thread Raw
In response to Re: limiting hint bit I/O  (Josh Berkus <josh@agliodbs.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: We need to log aborted autovacuums
Next
From: Peter Eisentraut
Date:
Subject: Re: texteq/byteaeq: avoid detoast [REVIEW]