Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization
Дата
Msg-id CA+TgmoYvL-tFgDdOdvVWSAxs1UeVQgRkonz8Ddy-8XDVMx2wKw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Unused variable scanned_tuples in LVRelStats
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] typo for using "OBJECT_TYPE" for "security label ondomain" in "gram.y"