Re: pgbench more operators & functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pgbench more operators & functions
Date
Msg-id 1282.1475682781@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgbench more operators & functions  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: pgbench more operators & functions  (Fabien COELHO <coelho@cri.ensmp.fr>)
Re: pgbench more operators & functions  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
Fabien COELHO <coelho@cri.ensmp.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



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: pgbench more operators & functions
Next
From: Artur Zakirov
Date:
Subject: Re: [PATCH] Generic type subscription