Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization
Date
Msg-id CA+TgmoYvL-tFgDdOdvVWSAxs1UeVQgRkonz8Ddy-8XDVMx2wKw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Aug 2, 2017 at 10:17 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Sure, but "no indexes at all" is hardly ever the real goal, is it?

Right.

> So the switch as proposed is only solving part of your problem.
> I'd rather see a solution that addresses a larger range of desires.

That's reasonable.

> Or in other words, this looks to me quite a bit like the hackery
> that resulted in pgbench's -S and -N options, before we figured out
> that making it scriptable was a better answer.

But it's not very clear to me how we could make this case scriptable,
and it would probably not be much different from just using the
proposed option and then running the script afterwards yourself via
psql.  The thing about -N and -S is that those scripts are being run
repeatedly, so pgbench has to be involved.  If you just want to create
different/extra indexes, you can do that yourself.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Unused variable scanned_tuples in LVRelStats
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] typo for using "OBJECT_TYPE" for "security label ondomain" in "gram.y"