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 |
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 |