Re: pgbench -f and vacuum

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tatsuo Ishii <ishii(at)postgresql(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgbench -f and vacuum
Date: 2014-12-15 16:29:26
Message-ID: CA+Tgmoah4wFEggTs18JCajZCfaCqWgxANk+DugTmnMqYzWm2BA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Dec 13, 2014 at 10:39 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Tatsuo Ishii <ishii(at)postgresql(dot)org> writes:
>> Currently pgbench -f (run custom script) executes vacuum against
>> pgbench_* tables before stating bench marking if -n (or --no-vacuum)
>> is not specified. If those tables do not exist, pgbench fails. To
>> prevent this, -n must be specified. For me this behavior seems insane
>> because "-f" does not necessarily suppose the existence of the
>> pgbench_* tables. Attached patch prevents pgbench from exiting even
>> if those tables do not exist.
>
> I don't particularly care for this approach. I think if we want to
> do something about this, we should just make -f imply -n. Although
> really, given the lack of complaints so far, it seems like people
> manage to deal with this state of affairs just fine. Do we really
> need to do anything?

I would vote for changing nothing. If we make -f imply -n, then what
happens if you have a script which is a slight variant of the default
script and you *don't* want -n? Then we'll have to add yet another
pgbench option to select the default behavior, and I don't know that
the marginal usability gain of getting to leave out -n sometimes would
be enough to justify having to remember another switch.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-12-15 16:30:40 Re: Something is broken in logical decoding with CLOBBER_CACHE_ALWAYS
Previous Message Craig Ringer 2014-12-15 16:28:36 Re: Making BackgroundWorkerHandle a complete type or offering a worker enumeration API?