Hello,
I think that the actual oversight is that the checkInitSteps should be
called at the beginning of processing initialization steps rather than
while processing -I, because currently other places modify the
initialization string (no-vacuum, foreign key) and thus are not checked.
As far
On Thu, Nov 7, 2019 at 6:35 PM Fabien COELHO wrote:
>
>
> Hello Masao-san,
>
> >> I do not think that this is desirable. It would be a regression, and
> >> allowing a no-op is not an issue in anyway.
> >
> > Why is that regression, you think?
>
> Because "pgbench -I ' d'" currently works and it wo
Hello Masao-san,
I do not think that this is desirable. It would be a regression, and
allowing a no-op is not an issue in anyway.
Why is that regression, you think?
Because "pgbench -I ' d'" currently works and it would cease to work after
the patch.
I think that's an oversight. If I'm m
On Thu, Nov 7, 2019 at 5:18 PM Fabien COELHO wrote:
>
>
> >>> I think that it may break --no-vacuum, and I thought that there may be
> >>> other option which remove things, eventually. Also, having a NO-OP looks
> >>> ok to me.
> >>
> >> As far as I read the code, checkInitSteps() checks the initi
I think that it may break --no-vacuum, and I thought that there may be
other option which remove things, eventually. Also, having a NO-OP looks
ok to me.
As far as I read the code, checkInitSteps() checks the initialization
steps that users specified. The initialization steps string that
"v"
2019-11-06 11:31 に Fujii Masao さんは書きました:
On Wed, Nov 6, 2019 at 6:23 AM Fabien COELHO
wrote:
Hello,
>>> - for (step = initialize_steps; *step != '\0'; step++)
>>> + for (const char *step = initialize_steps; *step != '\0'; step++)
>
> But I still wonder why we should apply such change here.
On Wed, Nov 6, 2019 at 6:23 AM Fabien COELHO wrote:
>
>
> Hello,
>
> >>> - for (step = initialize_steps; *step != '\0'; step++)
> >>> + for (const char *step = initialize_steps; *step != '\0'; step++)
> >
> > But I still wonder why we should apply such change here.
>
> Because it removes one decla
Hello,
- for (step = initialize_steps; *step != '\0'; step++)
+ for (const char *step = initialize_steps; *step != '\0'; step++)
But I still wonder why we should apply such change here.
Because it removes one declaration and reduces the scope of one variable?
If there is the reason why t
On Thu, Oct 31, 2019 at 11:54 PM Fabien COELHO wrote:
>
>
> Hello Masao-san,
>
> > + snprintf(sql, sizeof(sql),
> > + "insert into pgbench_branches(bid,bbalance) "
> > + "select bid, 0 "
> > + "from generate_series(1, %d) as bid", scale);
> >
> > "scale" should be "nbranches * scale".
>
> Yep, eve
Hello Masao-san,
If large scale factor is specified, the query for generating
pgbench_accounts data can take a very long time. While that query is
running, operators may be likely to do Ctrl-C to cancel the data
generation. In this case, IMO pgbench should cancel the query, i.e.,
call PQcan
Hello Masao-san,
+ snprintf(sql, sizeof(sql),
+ "insert into pgbench_branches(bid,bbalance) "
+ "select bid, 0 "
+ "from generate_series(1, %d) as bid", scale);
"scale" should be "nbranches * scale".
Yep, even if nbranches is 1, it should be there.
+ snprintf(sql, sizeof(sql),
+ "insert in
On Mon, Oct 28, 2019 at 10:36 PM Fabien COELHO wrote:
>
>
> Hello Masao-san,
>
> >> Maybe. If you cannot check, you can only guess. Probably it should be
> >> small, but the current version does not allow to check whether it is so.
> >
> > Could you elaborate what you actually want to measure the
Hello Masao-san,
Maybe. If you cannot check, you can only guess. Probably it should be
small, but the current version does not allow to check whether it is so.
Could you elaborate what you actually want to measure the performance
impact by adding explicit begin and commit? Currently pgbench -
On Fri, Oct 25, 2019 at 12:06 AM Fabien COELHO wrote:
>
>
> Hello,
>
> >> Yep. Or anything else, including without (), to allow checking the
> >> performance impact or non impact of transactions on the initialization
> >> phase.
> >
> > Is there actually such performance impact? AFAIR most time-co
Hello,
Yep. Or anything else, including without (), to allow checking the
performance impact or non impact of transactions on the initialization
phase.
Is there actually such performance impact? AFAIR most time-consuming part in
initialization phase is the generation of pgbench_accounts data
On Thu, Oct 24, 2019 at 9:16 PM Fabien COELHO wrote:
>
>
> Hello Masao-san,
>
> >> The benefit of controlling where begin/end actually occur is that it may
> >> have an impact on performance, and it allows to check that.
> >
> > I still fail to understand the benefit of addition of () settings.
>
Hello Masao-san,
The benefit of controlling where begin/end actually occur is that it may
have an impact on performance, and it allows to check that.
I still fail to understand the benefit of addition of () settings.
Could you clarify what case () settings are useful for? You are
thinking to
On Thu, Oct 17, 2019 at 8:09 PM Fabien COELHO wrote:
>
>
> Hello,
>
> > Failed regression test. It's necessary to change the first a in “allowed
> > step characters are” to uppercase A in the regression test of
> > 002_pgbench_no_server.pl.
>
> Argh. I think I ran the test, then stupidly updated t
Hello,
Failed regression test. It's necessary to change the first a in “allowed
step characters are” to uppercase A in the regression test of
002_pgbench_no_server.pl.
Argh. I think I ran the test, then stupidly updated the message afterwards
to better match best practices, without rechecki
Hi,
When g is specified, null is inserted in the filler column of
pgbentch_tellrs, acounts, branches.
But when G is specified, empty string is inserted.
Do you have any intention of this difference?
--
Anna
Here is rebase v3.
Hi,
Thanks for your new patch.
Failed regression test.
It's necessary to change the first a in “allowed step characters are” to
uppercase A in the regression test of 002_pgbench_no_server.pl.
The behavior of "g" is different between v12 and the patche, and
backward c
Attached v2 is a rebase after ce8f9467.
Here is rebase v3.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index e3a0abb4c7..e9f43f3b26 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -167,7 +167,7 @@ pgbench options d
Hello Fabien,
-- Forwarded message -
From: Fabien COELHO
Date: Tue, Jul 16, 2019 at 4:58 PM
Subject: Re: pgbench - extend initialization phase control
To: Ibrar Ahmed
Cc: PostgreSQL Developers
Hello Ibrar,
The following review has been posted through the commitfest
Hello Ibrar,
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
Other than that, the patch looks good to me.
Th
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
Other than that, the patch looks good to me.
The new status of t
Hello Ibrar,
Does both client/server side data generation in a single command make
sense?
I think yes, especially with the other patch which adds timing measures to
the initialization phases. It really depends what you want to test.
With client-side generation you test the libpq COPY inte
Does both client/server side data generation in a single command make sense?
Hello devs,
the attached patch adds some more control on the initialization phase.
In particular, ( and ) allow to begin/commit explicitely, and G generates
the data server-side instead of client side, which might be a good idea
depending on the available bandwidth.
Together with the previou
28 matches
Mail list logo
