Re: newbie design question re impact of VACUUM

In article <1131466149.590544.159870@g43g2000cwa.googlegroups.com>,
"shakahshakah@gmail.com" <shakahshakah@gmail.com> writes:

> As a background, I'll be using Postgres in part as a processing queue
> for a 40-column stream of information (~ 250 bytes/row) with a
> sustained input rate of 20 rows/sec. This queue will be processed
> periodically (every few minutes), design constraints are to (1) only
> process each row once, and (2) keep the processed rows around for a
> period of time (say a month or so).

> My first (naive?) idea was to add a boolean "was_processed" column to
> the table (defaulted to false) and UPDATE it to true as part of (1).
> After reading Chapter 22, though, it seems that even a minor UPDATE
> like that copies the row and requires VACUUMing.

That's true, but there might be a way to avoid it.  If your queue
elements have a timestamp, you could run your processing routine not
over elements where "was_processed" is false, but over elements within
some time interval, e.g. the last minute.  This would eliminate the
need for an UPDATE.