Tom Lane wrote: > The remaining degradation is actually in seqscan performance, not > indexscan --- unless one uses a much larger -s setting, the planner will > think it ought to use seqscans for updating the "branches" and "tellers" > tables, since those nominally have just a few rows; and there's no way > to avoid scanning lots of dead tuples in a seqscan. Forcing indexscans > helps some in the former CVS tip: >
This may qualify as a "way out there" idea, or more trouble than it's worth, but what about a table option which provides a bitmap index of tuple status -- i.e. tuple dead t/f. If available, a seqscan in between vacuums could maybe gain some of the same efficiency. > This is the first time I have ever seen repeated pgbench runs without > substantial performance degradation. Not a bad result for a Friday > afternoon... Nice work! Joe ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
