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

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Gregory Smith <gregsmithpgsql(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, david(dot)christensen(at)crunchydata(dot)com
Subject: Re: pgbench: INSERT workload, FK indexes, filler fix
Date: 2021-07-01 10:47:57
Message-ID: alpine.DEB.2.22.394.2107011226160.2024567@pseudo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-07-01 11:07:50 Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options
Previous Message David Rowley 2021-07-01 10:44:46 Re: Numeric multiplication overflow errors