| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pgbench more operators & functions |
| Date: | 2016-10-05 09:03:42 |
| Message-ID: | alpine.DEB.2.20.1610051058500.8581@lancre |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> I've got no objection to a more-nearly-TPC-B script as an option.
Good, because adding a "per-spec" tpc-b as an additional builtin option is
one of my intentions, once pgbench is capable of it.
> But why do you feel the need to pull the default script out into
> a separate file? Seems to me that just adds maintenance complexity,
> and the need for pgbench to have a notion of a library directory,
> for little gain.
I tend to agree on this point. Now it could be possible to make pgbench
look for "builtin" scripts in a predefined location so that they are found
easilly, but I'm not sure there would be a significant added value wrt the
current status.
--
Fabien.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2016-10-05 09:04:05 | Re: Dynamic shared memory areas |
| Previous Message | Amit Langote | 2016-10-05 08:59:04 | Re: Declarative partitioning - another take |