Re: pgbench -f and vacuum

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: michael(dot)paquier(at)gmail(dot)com
Cc: alvherre(at)2ndquadrant(dot)com, robertmhaas(at)gmail(dot)com, ishii(at)postgresql(dot)org, tv(at)fuzzy(dot)cz, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgbench -f and vacuum
Date: 2015-02-09 05:54:49
Message-ID: 20150209.145449.2175464237557137771.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>> Although that might be taking this thread rather far off-topic.
>> Not really sure about that, because the only outstanding objection to
>> this discussion is what happens in the startup stage if you specify -f.
>> Right now vacuum is attempted on the standard tables, which is probably
>> not the right thing in the vast majority of cases. But if we turn that
>> off, how do we reinstate it for the rare cases that want it? Personally
>> I would just leave it turned off and be done with it, but if we want to
>> provide some way to re-enable it, this --startup-script=FILE gadget
>> sounds like a pretty decent idea.
> (Catching up with this thread)
> Yes I think that it would be more simple to simply turn off the
> internal VACUUM if -f is specified. For the cases where we still need
> to vacuum the tables pgbench_*, we could simply document to run a
> VACUUM on them.

Agreed. Here is the patch to implement the idea: -f just implies -n.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

Attachment Content-Type Size
pgbench-f-noexit-v3.patch text/x-patch 1.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2015-02-09 06:18:04 Re: [REVIEW] Re: Compression of full-page-writes
Previous Message Tom Lane 2015-02-09 01:21:10 Re: RangeType internal use