On Mon, Jun 6, 2016 at 9:53 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Masahiko Sawada <sawada.m...@gmail.com> writes: >> On Sat, Jun 4, 2016 at 1:46 PM, Masahiko Sawada <sawada.m...@gmail.com> >> wrote: >>> So other idea is to have GUC parameter, vacuum_even_frozen_page for example. >>> If this parameter is set true (false by default), we do vacuum whole >>> table forcibly and re-generate visibility map. >>> The advantage of this idea is that we don't necessary to expand VACUUM >>> syntax and relatively easily can remove this parameter if it's not >>> necessary anymore. > >> Attached is a sample patch that controls full page vacuum by new GUC >> parameter. > > I find this approach fairly ugly ... it's randomly inconsistent with other > VACUUM parameters for no very defensible reason.
Just to be sure I understand, in what way is it inconsistent? > Taking out GUCs is not > easier than taking out statement parameters; you risk breaking > applications either way. Agreed, but that doesn't really answer the question of which one we should have, if either. My gut feeling on this is to either do nothing or add a VACUUM option (not a GUC, not a reloption) called even_frozen_pages, default false. What is your opinion? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
