Re: pgbench more operators & functions

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

In response to

Responses

Browse pgsql-hackers by date

  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