After looking at "Chapter 22. Routine Database Maintenance Tasks" (http://www.postgresql.org/docs/8.1/interactive/maintenance.html), I started wondering about what (if any) consideration to give to to VACUUM issues in the following context. 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. Given that, my basic question is whether row width is a consideration in UPDATE or VACUUM performance, and if so if it is generally accepted practice to design around it? For example, if I were to make a child table to effectively hold the "was_processed" flag I could probably avoid UPDATEs entirely, but I'm not sure how to value that in this context. Thanks in advance for and help/info/pointers. ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your message can get through to the mailing list cleanly
