In article <1131466149.590544.159870@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, "shakahshakah@xxxxxxxxx" <shakahshakah@xxxxxxxxx> 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. ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
