PATCH: Add Table Access Method option to pgbench

On Thu, Jun 30, 2022 at 09:09:17AM -0700, Michel Pelletier wrote:

This change was originally authored by Alexander Korotkov, I have updated
it and added a test to the pgbench runner. I'm hoping to make the deadline
for this currently open Commit Fest?

This is failing check-world
http://cfbot.cputube.org/michel-pelletier.html

BTW, you can test your patches the same as cfbot does (before mailing the list)
on 4 OSes by pushing a branch to a github account. See ./src/tools/ci/README

--
Justin

On Thu, 30 Jun 2022 at 09:51, Justin Pryzby <pryzby@telsasoft.com> wrote:

On Thu, Jun 30, 2022 at 09:09:17AM -0700, Michel Pelletier wrote:

This change was originally authored by Alexander Korotkov, I have updated
it and added a test to the pgbench runner. I'm hoping to make the

deadline

for this currently open Commit Fest?

This is failing check-world
http://cfbot.cputube.org/michel-pelletier.html

BTW, you can test your patches the same as cfbot does (before mailing the
list)
on 4 OSes by pushing a branch to a github account. See
./src/tools/ci/README

Ah that's very helpful thank you! This is my first patch submission so

sorry for any mixups.

-Michel

I've got CI setup and building and the tests now pass, I was missing a
CASCADE in my test. New patch attached:

On Thu, 30 Jun 2022 at 10:50, Michel Pelletier <michel@supabase.io> wrote:

On Thu, Jun 30, 2022 at 01:07:53PM -0700, Michel Pelletier wrote:

I've got CI setup and building and the tests now pass, I was missing a
CASCADE in my test. New patch attached:

The exact same patch has been proposed back in November 2020:
/messages/by-id/0177f78c-4702-69c9-449d-93cc93c7f8c0@highgo.ca

And the conclusion back then is that one can already achieve this by
using PGOPTIONS:
PGOPTIONS='-c default_table_access_method=wuzza' pgbench [...]

So there is no need to complicate more pgbench, particularly when it
comes to partitioned tables where USING is not supported. Your patch
touches this area of the client code to bypass the backend error.
--
Michael

On Fri, Jul 01, 2022 at 10:06:49AM +0900, Michael Paquier wrote:

And the conclusion back then is that one can already achieve this by
using PGOPTIONS:
PGOPTIONS='-c default_table_access_method=wuzza' pgbench [...]

So there is no need to complicate more pgbench, particularly when it
comes to partitioned tables where USING is not supported. Your patch
touches this area of the client code to bypass the backend error.

Actually, it could be a good thing to mention that directly in the
docs of pgbench.
--
Michael

On Thu, 30 Jun 2022 at 18:09, Michael Paquier <michael@paquier.xyz> wrote:

On Fri, Jul 01, 2022 at 10:06:49AM +0900, Michael Paquier wrote:

And the conclusion back then is that one can already achieve this by
using PGOPTIONS:
PGOPTIONS='-c default_table_access_method=wuzza' pgbench [...]

So there is no need to complicate more pgbench, particularly when it
comes to partitioned tables where USING is not supported. Your patch
touches this area of the client code to bypass the backend error.

Actually, it could be a good thing to mention that directly in the
docs of pgbench.

I've attached a documentation patch that mentions and links to the
PGOPTIONS documentation per your suggestion. I'll keep the other patch on
the back burner, perhaps in the future there will be demand for a command
line option as more TAMs are created.

Thanks,

-Michel

On Wed, Jul 13, 2022 at 12:33 AM Michel Pelletier <michel@supabase.io>
wrote:

On Thu, 30 Jun 2022 at 18:09, Michael Paquier <michael@paquier.xyz> wrote:

On Fri, Jul 01, 2022 at 10:06:49AM +0900, Michael Paquier wrote:

And the conclusion back then is that one can already achieve this by
using PGOPTIONS:
PGOPTIONS='-c default_table_access_method=wuzza' pgbench [...]

So there is no need to complicate more pgbench, particularly when it
comes to partitioned tables where USING is not supported. Your patch
touches this area of the client code to bypass the backend error.

Actually, it could be a good thing to mention that directly in the
docs of pgbench.

I've attached a documentation patch that mentions and links to the
PGOPTIONS documentation per your suggestion. I'll keep the other patch on
the back burner, perhaps in the future there will be demand for a command
line option as more TAMs are created.

The documentation change looks good to me

On Mon, Jul 18, 2022 at 12:08 AM Mason Sharp <masonlists@gmail.com> wrote:

On Wed, Jul 13, 2022 at 12:33 AM Michel Pelletier <michel@supabase.io> wrote:

On Thu, 30 Jun 2022 at 18:09, Michael Paquier <michael@paquier.xyz> wrote:

On Fri, Jul 01, 2022 at 10:06:49AM +0900, Michael Paquier wrote:

And the conclusion back then is that one can already achieve this by
using PGOPTIONS:
PGOPTIONS='-c default_table_access_method=wuzza' pgbench [...]

So there is no need to complicate more pgbench, particularly when it
comes to partitioned tables where USING is not supported. Your patch
touches this area of the client code to bypass the backend error.

Actually, it could be a good thing to mention that directly in the
docs of pgbench.

I've attached a documentation patch that mentions and links to the PGOPTIONS documentation per your suggestion. I'll keep the other patch on the back burner, perhaps in the future there will be demand for a command line option as more TAMs are created.

The documentation change looks good to me

Looks good to me as well. I'm going to push this if no objections.

------
Regards,
Alexander Korotkov

On Mon, Jul 18, 2022 at 01:53:21PM +0300, Alexander Korotkov wrote:

Looks good to me as well. I'm going to push this if no objections.

FWIW, I find the extra mention of PGOPTIONS with the specific point of
table AMs added within the part of the environment variables a bit
confusing, because we already mention PGOPTIONS for serializable
transactions a bit down. Hence, my choice would be the addition of an
extra paragraph in the "Notes", named "Table Access Methods", just
before or after "Good Practices". My 2c.
--
Michael

Hi!

On Tue, Jul 19, 2022 at 4:47 AM Michael Paquier <michael@paquier.xyz> wrote:

On Mon, Jul 18, 2022 at 01:53:21PM +0300, Alexander Korotkov wrote:

Looks good to me as well. I'm going to push this if no objections.

FWIW, I find the extra mention of PGOPTIONS with the specific point of
table AMs added within the part of the environment variables a bit
confusing, because we already mention PGOPTIONS for serializable
transactions a bit down. Hence, my choice would be the addition of an
extra paragraph in the "Notes", named "Table Access Methods", just
before or after "Good Practices". My 2c.

Thank you. Pushed applying the suggestion above.

------
Regards,
Alexander Korotkov