Re: Heavy write activity on first vacuum of fresh TOAST data - Mailing list pgsql-performance

From Kevin Grittner
Subject Re: Heavy write activity on first vacuum of fresh TOAST data
Date
Msg-id 476108F2.EE98.0025.0@wicourts.gov
Whole thread Raw
In response to Re: Heavy write activity on first vacuum of fresh TOAST data  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Heavy write activity on first vacuum of fresh TOAST data  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
>>> On Thu, Dec 13, 2007 at 10:11 AM, in message
<1197562283.4255.1829.camel@ebony.site>, Simon Riggs <simon@2ndquadrant.com>
wrote:
> On Thu, 2007-12-13 at 09:46 -0600, Kevin Grittner wrote:
>
>> The data was inserted through a Java program using a prepared
>> statement with no indexes on the table.  The primary key was then
>> added, and now I've started a vacuum.  The new table wound up being
>> the first big table vacuumed, and I noticed something odd.  Even
>> though there have been no rollbacks, updates, or deletes on this
>> table, the vacuum is writing as much as it is reading while dealing
>> with the TOAST data.
>
> Writing hint bits. Annoying isn't it? :-(

Surprising, anyway.  If it allows subsequent operations to be
faster, I'll take it; although to a naive user it's not clear what
is known at vacuum time that the INSERT into the empty table
couldn't have inferred.  Bulk loads into empty tables are a pretty
common use case, so if there was some way to set the hints on
insert, as long as the table started the database transaction
empty, nobody else is modifying it, and only inserts have occurred,
that would be a good thing.  I'm speaking from the perspective of a
user, of course; not someone who would actually try to wrangle the
code into working that way.

Thanks for the explanation.

-Kevin




pgsql-performance by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Limited performance on multi core server
Next
From: Tom Lane
Date:
Subject: Re: Heavy write activity on first vacuum of fresh TOAST data