Thread: PATCH: Add Table Access Method option to pgbench
Hello!
This patch adds a `--tableam=TABLEAM` option to the pgbench command line which allows the user to specify which table am is used to create tables initialized with `-i`.
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?
My goal is to add a couple more regression tests but the implementation is complete.
Thanks in advance for any comments or questions!
-Michel
Attachment
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, 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/READMEAh that's very helpful thank you! This is my first patch submission so sorry for any mixups.-Michel
Attachment
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: https://www.postgresql.org/message-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
Attachment
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
Attachment
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
--
Michael
Attachment
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'llkeep the other patch on the back burner, perhaps in the future there will be demand for a command line option as moreTAMs 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
Attachment
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