| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Subject: | Re: Freeze avoidance of very large table. |
| Date: | 2015-07-13 12:22:50 |
| Message-ID: | 20150713122250.GA9518@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2015-07-13 21:03:07 +0900, Sawada Masahiko wrote:
> Even If we implement rewriting tool for vm into pg_upgrade, it will
> take time as much as revacuum because it need whole scanning table.
Why would it? Sure, you can only set allvisible and not the frozen bit,
but that's fine. That way the cost for freezing can be paid over time.
If we require terrabytes of data to be scanned, including possibly
rewriting large portions due to freezing, before index only scans work
and most vacuums act in a partial manner the migration to 9.6 will be a
major pain for our users.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sawada Masahiko | 2015-07-13 12:22:55 | Re: Support for N synchronous standby servers - take 2 |
| Previous Message | Ildus Kurbangaliev | 2015-07-13 12:19:15 | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |