Re: Index tuple killing code committed

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