| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
| Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: autovacuum not prioritising for-wraparound tables |
| Date: | 2013-02-02 04:48:48 |
| Message-ID: | CAMkU=1yVGrP75Ps5PjVHWcQM6Be1WUqgqvfsuqEK4o3dhYKLxA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Monday, January 28, 2013, Kevin Grittner wrote:
> IMO, anything which changes an anti-wraparound vacuum of a
> bulk-loaded table from "read the entire table and rewrite nearly
> the complete table with WAL-logging" to rewriting a smaller portion
> of the table with WAL-logging is an improvement. Anyone who has
> run an OLTP load on a database which was loaded from pg_dump output
> or other bulk load processes, has probably experienced the pain
> related to the WAL-logged rewrite of massive quantities of data.
>
pgbench seems to be the OLTP load par excellence (or perhaps ad nauseum).
What other set up is needed to get it to reproduce this problem? Do we
just do a dump/restore in lieu of pgbench -i?
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2013-02-02 09:23:21 | proposal 9.4 plpgsql: allows access to call stack from GET DIAGNOSTICS statement |
| Previous Message | Tom Lane | 2013-02-02 00:24:02 | Re: GetOldestXmin going backwards is dangerous after all |