Excerpts from Michael Renner's message of sáb may 15 20:24:36 -0400 2010: > On 16.05.2010 02:16, Tom Lane wrote: > > Michael Renner<michael.ren...@amd.co.at> writes: > >> I've written a simple tool to generate traffic on a database [1], which > >> did about 30 TX/inserts per second to a table. Upon inspecting the data > >> in the table, I noticed the expected grouping of tuples which came from > >> a single backend to matching pages [2]. The strange part was that the > >> pages weren't completely filled but the backends seemed to jump > >> arbitrarily from one page to the next [3]. For the table in question > >> this resulted in about 10% wasted space. > > > > Which table would that be? The trigger-driven updates to "auction", > > in particular, would certainly guarantee some amount of "wasted" space. > > Yeah, the auction table receives heavy updates and gets vacuumed regularly. > > The behavior I showed was for the "bid" table, which only gets inserts > (and triggers the updates for the auction table).
I think this may be related to the smgr_targblock stuff; if the relcache entry gets invalidated at the wrong time for whatever reason, the "current page" could be abandoned in favor of extending the rel. This has changed since 8.4, but a quick perusal suggests that it should be less likely on 9.0 than 8.4 but maybe there's something weird going on. -- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
