Re: pgbench -f and vacuum
От | Tatsuo Ishii |
---|---|
Тема | Re: pgbench -f and vacuum |
Дата | |
Msg-id | 20141214.091732.1633743031163949886.t-ishii@sraoss.co.jp обсуждение исходный текст |
Ответ на | Re: pgbench -f and vacuum (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: pgbench -f and vacuum
|
Список | pgsql-hackers |
> On 14 December 2014 at 04:39, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> >> Tatsuo Ishii <ishii@postgresql.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 also find this weird vacuum non existing tables rather bizarre. I think > the first time I ever used pgbench I was confronted by the pgbench* tables > not existing, despite the fact that I was trying to run my own script. > Looking at --help it mentioned nothing about the pgbench_* tables, so I was > pretty confused until I opened up the online docs. > > I'm not really a fan of how this is done in the proposed patch, I'd vote > for either skipping vacuum if -f is specified, or just doing a database > wide vacuum in that case. Though, that might surprise a few people, so > maybe the first option is better. Problem with "-f implies -n" approach is, it breaks backward compatibility. There are use cases using custom script *and* pgbench_* tables. For example the particular user wants to use the standard pgbench tables and is not satisfied with the built in scenario. I know at least one user does this way. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
В списке pgsql-hackers по дате отправления: