From: | Michael Renner <michael(dot)renner(at)amd(dot)co(dot)at> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Unexpected page allocation behavior on insert-only tables |
Date: | 2010-05-16 00:24:36 |
Message-ID: | 4BEF3B44.5010402@amd.co.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 16.05.2010 02:16, Tom Lane wrote:
> Michael Renner<michael(dot)renner(at)amd(dot)co(dot)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).
best regards,
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-05-16 01:22:10 | Re: [PATCH] Add SIGCHLD catch to psql |
Previous Message | Tom Lane | 2010-05-16 00:16:47 | Re: Unexpected page allocation behavior on insert-only tables |