Re: pgbench: INSERT workload, FK indexes, filler fix

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: pgbench: INSERT workload, FK indexes, filler fix
Дата
Msg-id alpine.DEB.2.22.394.2107011226160.2024567@pseudo
обсуждение исходный текст
Ответ на pgbench: INSERT workload, FK indexes, filler fix  (Gregory Smith <gregsmithpgsql@gmail.com>)
Ответы Re: pgbench: INSERT workload, FK indexes, filler fix
Список pgsql-hackers
Hello Greg,

Some quick feedback about the patch and the arguments.

Filling: having an empty string/NULL has been bothering me for some time. 
However there is a significant impact on the client/server network stream 
while initializing or running queries, which means that pgbench older 
performance report would be comparable to newer ones, which is a pain even 
if the new results do make sense, as you noted in a comment. I'm okay with 
breaking that, but it would require a consensus: People would run pgbench 
on a previous install, upgrade, run pgbench again, and report a massive 
performance regression. Who will have to deal with that noise?

A work around could be to add new workloads with different names, and let 
the previous workloads more or less as is.

"--insert-only" as a short hand for "-b insert-only": I do not think this 
is really needed to save 1 char. Also note that "-b i" would probably 
work.

extra indexes: I'm ok on principle. Do we want an option for that though? 
Isn't adding "i" to -I enough? Also I do not like much the code which 
modifies the -I provided string to add a "i".

> After bouncing the possibilities around a little, David and I thought this
> specific set of changes might be the right amount of change for one PG
> version.

Hmmm. I was hoping for more changes:-) Eg the current error handling patch 
would be great.

> benchmark noise from where I started at with PG.  The $750 USD AMD retail
> chip in my basement lab pushes 1M TPS of prepared SELECT statements over
> sockets.  Plus or minus 84 bytes per row in a benchmark database doesn't
> worry me so much anymore.

AFAICR the space is actually allocated by pg and filled with blanks, just 
not transfered by the protocol? For an actual network connection I guess 
the effect should be quite noticeable.

> [...]
> I personally would prefer to see pgbench lead by example here, that tables
> related this way should be indexed with FKs by default, as the Right Way to
> do such things.

I do agree that the default should be the good choices, and that some 
manual effort should be done to get the bad ones. The only issue is that 
people do not like change.

-- 
Fabien.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Numeric multiplication overflow errors
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options