From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
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 15:53:01 |
Message-ID: | 1282.1475682781@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> writes:
> [ re TPC-B ]
> (1) The required schema is slightly different : currently the type used
> for holding balances is not wide enough per the TCP-B standard, this mean
> maybe having an option to do "pgbench -i --standard-tpcb" which would
> generate the right schema, probably it should just change a few INTEGER to
> INT8, or maybe use NUMERIC(10). I have not done such a patch yet.
The whole question of the database setup is an interesting one. If we
were to do anything at all here, I'd want to see not only the table
schemas and initial population, but also the hard-wired "vacuum" logic,
somehow made not so hard-wired. I have no good ideas about that. The
SQL commands could possibly be taken from scripts, but what of all the
work that's gone into friendly progress reporting for table loading?
> (2) The benchmark specification requires the client application to get
> hold of query results, which are currently discarded by pgbench, so
> pgbench does not really comply. I have submitted a patch to do that, see:
I find this completely bogus. The data is delivered to the client,
ie it's inside the pgbench process. What's the grounds for arguing
that something else has to happen to it?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Artur Zakirov | 2016-10-05 15:59:38 | Re: [PATCH] Generic type subscription |
Previous Message | Fabien COELHO | 2016-10-05 15:17:38 | Re: pgbench more operators & functions |