From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Index tuple killing code committed |
Date: | 2002-05-24 21:38:41 |
Message-ID: | 3CEEB2E1.4090807@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-05-24 22:09:06 | Re: Index tuple killing code committed |
Previous Message | Tom Lane | 2002-05-24 21:28:13 | Re: Exposed function to find table in schema search list? |