On 2021-01-15 1:22 p.m., Andres Freund wrote:
Hi,
On 2020-11-25 12:41:25 +0900, Michael Paquier wrote:
On Tue, Nov 24, 2020 at 03:32:38PM -0800, David Zhang wrote:
But, providing another option for the end user may not be a bad idea, and it
might make the tests easier at some points.
My firs
On Fri, Jan 15, 2021 at 01:22:45PM -0800, Andres Freund wrote:
> I think that objection is right. All that's needed to change this from
> the client side is to do something like
> PGOPTIONS='-c default_table_access_method=foo' pgbench ...
>
> I don't think adding pgbench options for individual GUC
Hi,
On 2020-11-25 12:41:25 +0900, Michael Paquier wrote:
> On Tue, Nov 24, 2020 at 03:32:38PM -0800, David Zhang wrote:
> > But, providing another option for the end user may not be a bad idea, and it
> > might make the tests easier at some points.
>
> My first thought is that we have no need to
Hi,
`v6-0001-add-table-access-method-as-an-option-to-pgbench` fixed the
wording problems for pgbench document and help as they were pointed out
by Justin and Youichi.
`0001-update-tablespace-to-keep-document-consistency` is trying to make
the *tablespace* to be more consistent in pgbench doc
On 2021-01-09 5:44 a.m., youichi aramaki wrote:
+ " create tables with using specified
table access method,\n"
In my opinion, this sentence should be "create tables with specified table access
method" or "create tables using specified table access m
>+ " create tables with using
>specified table access method,\n"
In my opinion, this sentence should be "create tables with specified table
access method" or "create tables using specified table access method".
"create tables with specified table access
tablespace is an extraneous word ?
Thanks a lot for pointing this out. I will fix it in next patch once get all
issues clarified.
On Sun, Dec 27, 2020 at 09:14:53AM -0400, Fabien COELHO wrote:
src/test/regress/sql/create_am.sql:CREATE ACCESS METHOD heap2 TYPE TABLE
HANDLER heap_tableam_hand
On Sun, Dec 27, 2020 at 09:14:53AM -0400, Fabien COELHO wrote:
> > src/test/regress/sql/create_am.sql:CREATE ACCESS METHOD heap2 TYPE TABLE
> > HANDLER heap_tableam_handler;
> > ...
> > src/test/regress/sql/create_am.sql:DROP ACCESS METHOD heap2;
>
> > Or maybe using SET default_tablespace instea
Hello Justin,
src/test/regress/sql/create_am.sql:CREATE ACCESS METHOD heap2 TYPE TABLE
HANDLER heap_tableam_handler;
...
src/test/regress/sql/create_am.sql:DROP ACCESS METHOD heap2;
Or maybe using SET default_tablespace instead of modifying the CREATE sql.
That'd need to be done separately
> --- a/doc/src/sgml/ref/pgbench.sgml
> +++ b/doc/src/sgml/ref/pgbench.sgml
> @@ -359,6 +359,16 @@ pgbench options
> d
>
>
>
> +
> +
> --table-access-method=TABLEAM
> +
> +
> +Create tables using the specified table access method, rather than
> t
Again, thanks a lot for the feedback.
On 2020-12-02 12:03 p.m., Fabien COELHO wrote:
Hello David,
Some feedback about v4.
It looks that the option is *silently* ignored when creating a
partitionned table, which currently results in an error, and not
passed to partitions, which would accept
Hello David,
Some feedback about v4.
It looks that the option is *silently* ignored when creating a partitionned
table, which currently results in an error, and not passed to partitions,
which would accept them. This is pretty weird.
The input check is added with an error message when both p
Thanks a lot for the comments, Fabien.
Some feedback about v3:
In the doc I find TABLEACCESSMETHOD quite hard to read. Use TABLEAM
instead?
Yes, in this case, *TABLEAM* is easy to read, updated.
Also, the next entry uses lowercase (tablespace), why change the style?
The original style is not
Hello David,
Some feedback about v3:
In the doc I find TABLEACCESSMETHOD quite hard to read. Use TABLEAM
instead? Also, the next entry uses lowercase (tablespace), why change the
style?
Remove space after comma in help string. I'd use the more readable TABLEAM
in the help string rather th
Thanks Fabien for the comments.
On 2020-11-25 11:29 p.m., Fabien COELHO wrote:
Hello David,
The previous patch was based on branch "REL_13_STABLE". Now, the
attached new patch v2 is based on master branch. I followed the new
code structure using appendPQExpBuffer to append the new clause
"u
Thanks a lot again for the review and comments.
On 2020-11-25 9:36 p.m., Michael Paquier wrote:
On Wed, Nov 25, 2020 at 12:13:55PM -0800, David Zhang wrote:
The previous patch was based on branch "REL_13_STABLE". Now, the attached
new patch v2 is based on master branch. I followed the new code
Hello David,
The previous patch was based on branch "REL_13_STABLE". Now, the attached new
patch v2 is based on master branch. I followed the new code structure using
appendPQExpBuffer to append the new clause "using TABLEAM" in a proper
position and tested. In the meantime, I also updated th
On Wed, Nov 25, 2020 at 12:13:55PM -0800, David Zhang wrote:
> The previous patch was based on branch "REL_13_STABLE". Now, the attached
> new patch v2 is based on master branch. I followed the new code structure
> using appendPQExpBuffer to append the new clause "using TABLEAM" in a proper
> posit
Thank a lot for your comments, Michael.
On 2020-11-24 7:41 p.m., Michael Paquier wrote:
On Tue, Nov 24, 2020 at 03:32:38PM -0800, David Zhang wrote:
But, providing another option for the end user may not be a bad idea, and it
might make the tests easier at some points.
My first thought is that
On Tue, Nov 24, 2020 at 03:32:38PM -0800, David Zhang wrote:
> But, providing another option for the end user may not be a bad idea, and it
> might make the tests easier at some points.
My first thought is that we have no need to complicate pgbench with
this option because there is a GUC able to d
20 matches
Mail list logo
