From: | Mason Sharp <masonlists(at)gmail(dot)com> |
---|---|
To: | Michel Pelletier <michel(at)supabase(dot)io> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: PATCH: Add Table Access Method option to pgbench |
Date: | 2022-07-17 21:07:59 |
Message-ID: | CA+rR5x1vhKM4-no2N_4CZrvN4aCM1+6kHkW0sAKd3c39x-Hx5A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 13, 2022 at 12:33 AM Michel Pelletier <michel(at)supabase(dot)io>
wrote:
> On Thu, 30 Jun 2022 at 18:09, Michael Paquier <michael(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-07-17 22:25:19 | Re: postgres_fdw versus regconfig and similar constants |
Previous Message | Tom Lane | 2022-07-17 20:06:28 | Re: Use -fvisibility=hidden for shared libraries |