Hello Tom,
The attached patch teaches psql to redisplay any not-yet-executed
query text after editing with \e.
[...]
I've tested this patch. Although I agree that it is an improvement, I'm a
little at odd with the feature as is:
psql=> \e
# select 1...
then:
psql=> select 1...
Bonjour Vik,
Is quoting the spec good enough?
SQL:2016 Part 2 Foundation Section 7.10 :
Ah, this is the one information I did not have when reviewing Peter's
patch.
::=
USING[ AS ]
::=
I think possibly what the spec says (and that neither my patch nor
Peter's implements)
Hello Tom,
psql=> select 1...
psql->
I cannot move back with readline to edit further, I'm stuck there, which
is strange.
I don't follow. readline doesn't allow you to edit already-entered lines
today, that is, after typing "select 1" you see
regression=# select 1
regression-#
a
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
Hello Devs,
This patch moves duplicated query cancellation code code from psql &
scripts to fe-utils, so that it is shared and may be used by other
commands.
This is because Masao-san suggested to add a query cancellation feature to
pgbench for long queries (server-side data generation bein
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,
I give a quick look and I think we can
void
psql_setup_cancel_handler(void)
{
setup_cancel_handler(psql_sigint_callback);
}
Because it does not matter for setup_cancel_handler what we passed
because it is ignoring that in case of windows.
The "psql_sigint_callback" function is
Hello Alvaro,
#include "common/int.h"
#include "common/logging.h"
-#include "fe_utils/conditional.h"
#include "getopt_long.h"
#include "libpq-fe.h"
+#include "fe_utils/conditional.h"
+#include "fe_utils/cancel.h"
#include "pgbench.h"
#include "portability/instr_time.h"
wtf?
I underst
I understand that you are unhappy about something, but where the issue is
fails me, the "wtf" 3 characters are not enough to point me in the right
direction. Feel free to elaborate a little bit more:-)
I don't see why you move the "conditional.h" line out of its correct
alphabetical position (
Then you need to add #include libpq-fe.h in cancel.h. Our policy is
that headers compile standalone (c.h / postgres_fe.h / postgres.h
excluded).
Ok. I do not make a habit of adding headers in postgres, so I did not
notice there was an alphabetical logic to that.
Attached patch v4 does it.
Hello Tom,
I was suggesting something much simpler than rethinking readline handling.
Does not mean that it is a good idea, but while testing the patch I would
have liked the unfinished line to be in the current editing buffer,
basically as if I had not typed .
I did experiment with trying to
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
Hello Andres,
Attached v3 shorten some lines and adds "append_tablespace".
A v4 which just extends the patch to newly added 'G'.
I'd prefer not to expand the use of pqexpbuffer in more places, and
instead rather see this use StringInfo, now that's also available to
frontend programs.
Fran
It looks like don't define sigint_interrupt_jmp and
sigint_interrupt_enabled on Windows, yet they are still declared and
referenced?
Indeed, I put it on the wrong side of a "#ifndef WIN32".
Basically it is a false constant under WIN32, which it seems does not have
sigint handler, but the co
Patch v4 is a just a rebase.
--
Fabien.diff --git a/src/bin/pgbench/Makefile b/src/bin/pgbench/Makefile
index f402fe7b91..e1d3ef9bb3 100644
--- a/src/bin/pgbench/Makefile
+++ b/src/bin/pgbench/Makefile
@@ -10,6 +10,7 @@ include $(top_builddir)/src/Makefile.global
OBJS = \
$(WIN32RES) \
expr
. It would be a regression, and
allowing a no-op is not an issue in anyway.
--
Fabien Coelho - CRI, MINES ParisTech
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
, so that will have to change. There's probably some
spacing/padding issues I haven't thought of. Please try it out, make some
modifications to existing document pages to see how badges would work in
those contexts.
--
Fabien Coelho - CRI, MINES ParisTech
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
all.
6. I'm not quite sure how to handle terms that have different definitions
in different contexts. Should that be two glossdefs following one
glossterm, or two separate def/term pairs?
Please review and share your thoughts.
--
Fabien Coelho - CRI, MINES ParisTech
Hello Andres,
I don't think there's been any relevant code changes since the last
success.
last success:
2019-11-09 09:20:28.346 CET [28785:1] LOG: starting PostgreSQL 13devel on
x86_64-pc-linux-gnu, compiled by gcc (GCC) 10.0.0 20191102 (experimental),
64-bit
first failure:
2019-11-09 11
so it sure looks like a gcc upgrade caused the failure. But it's not
clear wheter it's a compiler bug, or some undefined behaviour that
triggers the bug.
Fabien, any chance to either bisect or get a bit more information on
the backtrace?
There is a promising "keep_error_builds" option in bui
Hello,
I did a (slow) dichotomy on gcc sources which determined that gcc r277979
was the culprit, then I started a bug report which showed that the issue
was already reported this morning by Martin Liška, including a nice
example isolated from sources. See:
https://gcc.gnu.org/bugzi
Yep, I build periodically PostgreSQL package in openSUSE with the latest
GCC and so that I identified that and isolated to a simple test-case. I
would expect a fix today or tomorrow.
Indeed, the gcc issue reported seems fixed by gcc r278259. I'm updating
moonjelly gcc to check if this solve
Yes, after the revision I see other failing tests like:
Indeed, I can confirm there are still 18/195 fails with the updated gcc.
I'm going to investigate that and will inform you guys.
Great, thanks!
--
Fabien.
Hello Martin,
The issue is resolved now and tests are fine for me.
I recompiled gcc trunk and the moonjelly is back to green.
Thanks!
--
Fabien.
I think that rl_insert_text and friends can probably only be used from
readline callback functions. So in principle maybe you could make it
work by having an rl_startup_hook that injects text if there is any
to inject. There would remain the issues of (a) is it portable across
a wide range of
Hello Tom,
While we're talking about copyrights, I noticed while researching
something else that the PHP project recently got rid of all the
copyright years from their files, which is one less thing to update and
one less cause of noise in the change log for rarely-changed files. Is
there ac
Bonjour Michaël,
Please note that you have received comments on this patch a couple of
weeks ago. The patch was still marked as "needs review", which was
incorrect, and it does not apply. Perhaps you did not notice it, so I
am moving it to next CF, waiting on author for a rebase and for
repli
Michaël,
Not this round.
You have registered yourself as a reviewer of this patch since the end
of June. Could you please avoid that? Sometimes people skips patches
when they see someone already registered to review it.
Yep. ISTM that I did a few reviews on early versions of the patch, wh
Hello Amit,
I wonder why we don't use the same style for $subject as pg_basebackup
--progress, that is, use a carriage return instead of a newline after
each line reporting the number of tuples copied?
Why not.
Attached patch for that.
I'll look into it. Could you add it to the CF app?
Bonjour Michaël,
The query cancellation added to pgbench is different than the actual
refactoring, and it is a result of the refactoring, so I would rather
split that into two different commits for clarity. The split is easy
enough, so that's fine not to send two different patches.
Yep, diff
Michaël,
+ boolaset;
It seems to me that there is no point to have the variable aset in
Command because this structure includes already MetaCommand, so the
information is duplicated. [...] Perhaps I am missing something?
Yep. ISTM that you are missing that aset is not an independ
I wonder why we don't use the same style for $subject as pg_basebackup
--progress, that is, use a carriage return instead of a newline after
each line reporting the number of tuples copied?
Patch applies cleanly, compiles, and works for me.
My 0.02€:
fprintf -> fputs or fputc to avoid a form
Hello Amit,
I have updated the patch based on these observations. Attached v2.
Patch v2 applies & compiles cleanly, works for me.
I'm not partial to Hungarian notation conventions, which is not widely
used elsewhere in pg. I'd suggest eolchar -> eol or line_end or whatever,
but others ma
I wrote the v1 patch on CentOS Linux, and now on MacOS. It would be
great if someone can volunteer to test on Windows terminal.
I do not have that.
Attached v3.
Patch applies, compiles, works for me. No further comments.
I switched the patch as ready.
--
Fabien.
The below addition can be removed, it seems to be duplicate:
Indeed. I'm unsure how this got into the patch, probably some rebase mix-up.
Attached v7 removes the duplicates.
Attached patch v8 is a rebase.
--
Fabien.diff --git a/contrib/pg_stat_statements/expected/pg_stat_statements.out b/
Another question I have is why doing only that for the data
initialization phase? Wouldn't it make sense to be consistent with the
other tools having --progress and do the same dance in pgbench's
printProgressReport()?
I thought of it but did not suggest it.
When running a bench I like se
Bonjour Michaël,
Committed the patch after splitting things into two commits and after
testing things from Linux and from a Windows console: the actual
refactoring and the pgbench changes.
I have found that we have a useless declaration of CancelRequested in
common.h, which is already part
Attached v4.
Patch applies cleanly, compiles, works for me. Put it back to ready.
--
Fabien.
Hello Craig,
New users frequently attempt to run PostgreSQL's command line utilities
from the psql prompt.
Alas, that is true.
I also have the reverse, i.e. SQL commands fed to bash, which does not
like it much.
They tend to be confused when this appears to do absolutely nothing:
explain (analyze) select * from pgbench_accounts \watch 1
It behaves as expected. But once I break out of the loop with ctrl-C, then
if I execute the same thing again it executes the command once, but shows
no output and doesn't loop. It seems like some flag is getting set with
ctrl-C, but t
I've not dug into code itself, I just bisected it.
Thanks for the report. I'll look into it.
Looked at it already.
Ah, the magic of timezones!
And yes, I can see the difference. This comes from the switch from
cancel_pressed to CancelRequested in psql, especially PSQLexecWatch() in
th
Hello Tom,
My 0.02 €:
Given the rather small number of existing uses of CancelRequested,
I wonder if it wouldn't be a better idea to rename it to cancel_pressed?
I prefer the former because it is more functional (a cancellation has been
requested, however the mean to do so) while "pressed"
Bonjour Michaël, hello devs,
As suggested in "cce64a51", this patch make pgbench use postgres logging
capabilities.
I tried to use fatal/error/warning/info/debug where appropriate.
Some printing to stderr remain for some pgbench specific output.
The patch fixes a inconsistent test case name
Bonjour Michaël,
the syscache mainly, so instead the attached patch does the following
changes:
- amapi.h -> indexam.h
- amapi.c -> indexamapi.c. Here we have an equivalent in access/table/
as tableamapi.c.
- amvalidate.c -> indexamvalidate.c
- amvalidate.h -> indexamvalidate.h
- genam.c -> in
On Tue, 17 Sep 2019, Alvaro Herrera wrote:
Indeed, that seems like a problem, and it's a good question. You can
see this on unpatched master with SELECT x.filler FROM
(pgbench_tellers AS t JOIN b USING (bid)) AS x.
I'm not sure I understand why that problem is a blocker for this patch.
As
Hello Justin,
I started writing this patch to avoid the possibly-misleading phrase: "with no
extra space" (since it's expected to typically take ~2x space, or 1x "extra"
space).
But the original phrase "with no extra space" seems to be wrong anyway, since
it actually follows fillfactor, so sa
Re-added -hackers.
Indeed, I left it out by accident. I tried to bounce the original mail but
it did not work.
Thanks for reviewing.
On Fri, Dec 27, 2019 at 05:22:47PM +0100, Fabien COELHO wrote:
The implementation simply extends an existing functions with a boolean to
allow for sub
Hello Justin,
Why not simply showing the files underneath their directories?
/path/to/tmp/file1
/path/to/tmp/subdir1/file2
In which case probably showing the directory itself is not useful,
and the is_dir column could be dropped?
The names are expected to look like this:
$ sudo find /v
Hello Justin,
Ok, so this suggests recursing into subdirs, which requires to make a
separate function of the inner loop.
Yea, it suggests that; but, SRF_RETURN_NEXT doesn't make that very easy.
It'd need to accept the fcinfo argument, and pg_ls_dir_files would call it once
for every tuple to
Bonsoir Vik,
I recently came across the need for a gcd function (actually I needed
lcm) and was surprised that we didn't have one.
Why not.
So here one is, using the basic Euclidean algorithm. I made one for
smallint, integer, and bigint.
Should pg provide the LCM as well? Hmmm, probably
Hello Tom,
We've often talked about the problem that we have no regression test
coverage for psql's tab completion code. I got interested in this
issue while messing with the filename completion logic therein [1],
so here is a draft patch that adds some testing for that code.
This is just pr
Hello Tom,
We've often talked about the problem that we have no regression test
coverage for psql's tab completion code. I got interested in this
issue while messing with the filename completion logic therein [1],
so here is a draft patch that adds some testing for that code.
After you rai
Bonjour Vik,
Should there be a NUMERIC version as well? I'd say maybe yes.
I thought about that, too, but also decided against it for this patch.
Hmmm. ISTM that int functions are available for numeric?
I'm wondering what it should do on N, 0 and 0, 0. Raise an error?
Return 0? Return 1?
Hello,
Because I do not trust C modulo as I had a lot of problems with it?:-)
If I recall correctly (and I'm traveling and away from those notes),
the exact semantics of C's % with negative operands was left
implementation-defined until, was it, C99 ?
Indeed, my woes with C % started befor
Hello Tom,
If you have to install IO::Pty anyway, ISTM you can also install Expect.
My point is precisely that buildfarm owners *won't* have to install
IO::Pty; it comes in a default Perl install almost everywhere.
I'm afraid that's not true of Expect.
Hmmm. That is a good argument.
Now
I'm not fan of relying on the configure stuff ("with_readline"), in my
Expect version I tested if history capabilities are available from psql
itself.
No, I disagree with that. If configure thinks it built with readline,
and then the actual binary acts like it doesn't have readline, that's
a
That is what my patch does: it tests prompts, tab completion, help,
command options… and I added tests till I covered most psql source.
Well, I think that where possible we ought to test using the existing
test infrastructure -- help, for example, seems like it could perfectly
well be tested
Hello Tom,
I do not think it is a good idea, because help output is quite large,
there are many of them, and we should certainly not want it stored
repeatedly in output files for diffs.
Hm, I don't follow --- we are most certainly not going to exercise
\help for every possible SQL keyword, t
Bonjour Michaël, et excellente année 2020 !
Hmm. Wouldn't it make sense to output the log generated as
information from the test using pg_log_info() instead of using
fprintf(stderr) (the logs of the initial data load, progress report)?
For the progress report, the reason I decided against is
Hello Peter,
The patch seems pretty straightforward, but this
+/*
+ * Convenient shorcuts
+ */
+#define fatal pg_log_fatal
+#define error pg_log_error
+#define warning pg_log_warning
+#define info pg_log_info
+#define debug pg_log_debug
seems counterproductive. Let's just use the normal func
Normally gcd() returns a positive integer, and gcd(a,0) = gcd(a,a) =
abs(a). But since abs(INT_MIN) cannot be represented as a 32-bit
integer, both those cases should throw an integer-out-of-range error.
I'm also in favor of that option, rather than sending a negative result as
a result.
A
Hello Peter,
Compared to v1 I have also made a few changes to be more consistent when
using fatal/error/info.
The renaming of debug to debug_level seems unnecessary and unrelated.
Indeed. It was when I used "debug" as a shorthand for "pg_log_debug".
In runShellCommand(), you removed some b
Hello Peter,
The documentation and pgbench --help output that accompanied this patch
claims that the argument to pgbench --partition-method is optional and
defaults to "range", but that is not actually the case, as the
implementation requires an argument. Could you please sort this out?
AFAI
Hello Peter,
I took another crack at this. Attached is a new patch that addresses
the semantic comments from this and the other thread. It's all a bit
tricky, comments welcome.
It seems that this patch does not apply anymore after Tom's 5815696.
--
Fabien.
Bonsoir Vik,
+int4gcd_internal(int32 arg1, int32 arg2)
+{
+ int32 swap;
+
+ /*
+* Put the greater value in arg1.
+* This would happen automatically in the loop below, but avoids an
+* expensive modulo simulation on some architectures.
+*/
t seems ok.
--
Fabien Coelho - CRI, MINES ParisTech
Hello Tom,
Which architecture has single cycle division? I think it's way above
that, based on profiles I've seen. And Agner seems to back me up:
https://www.agner.org/optimize/instruction_tables.pdf
That lists a 32/64 idiv with a latency of ~26/~42-95 cycles, even on a
moder uarch like skylak
Bonjour Vik,
Here is an updated patch fixing that.
As I said, welcome to arithmetic:-)
Patch v5 applies cleanly.
Doc: I'd consider using an example the result of which is 42 instead of
21, for obvious geek motivations. Possibly gcd(2142, 462) should be ok.
I got it wrong with my previou
Hello Vik,
Add unlikely() where appropriate.
Any particular place in mind where I didn't already put it?
In GCD implementations, for instance:
if (arg1 == PG_INT32_MIN)
if (arg2 == 0 || arg2 == PG_INT32_MIN)
And possibly a "likely" on the while.
In LCM implementations, for instance:
This patch was marked as RFC on 2019-03-30, but since then there have
been a couple more issues pointed out in a review by Thomas Munro, and
it went through 2019-09 and 2019-11 without any attention. Is the RFC
status still appropriate?
Thomas review was about comments/documentation wording
Hello Karl,
Attached is doc_base64_v11.patch
Patch applies cleanly and compiles.
I'm in favor of moving and reorganizing these function descriptions, as
they are somehow scattered with a unclear logic when you are looking for
them.
+ bytea ||
+bytea
bytea
Bonjour Michaël,
Without looking at the context I thought that argv[0] was the program name,
which is not the case here. I put it back everywhere, including the DEBUG
message.
The variable names in Command are confusing IMO...
Somehow, yes. Note that there is a logic, it will indeed be the
Hello Robert,
if (arg1 == PG_INT32_MIN)
if (arg2 == 0 || arg2 == PG_INT32_MIN)
And possibly a "likely" on the while.
I don't think decoration the code with likely() and unlikely() all
over the place is a very good idea.
Odds are good that we'll end up with a bunch that are actually
no
Hello Merlin,
For low-level arithmetic code like this one, with tests and loops
containing very few hardware instructions, I think that helping compiler
optimizations is a good idea.
Do you have any performance data to back that up?
Yep.
A generic data is the woes about speculative executi
Bonjour Michaël,
I think that I would just remove the "debug" variable defined in
pgbench.c all together, and switch the messages for the duration and the
one in executeMetaCommand to use info-level logging..
Ok, done.
Thanks. The output then gets kind of inconsistent when using --debug:
p
Patch v5 attached tries to follow your above suggestions.
Patch v6 makes syntax error location code more compact and tests the case.
--
Fabien.diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index a1e0663c8b..cfb5110608 100644
--- a/src/bin/pgbench/pgbench.c
+++ b/src/bin/p
Patch v6 makes syntax error location code more compact and tests the case.
Committed.
Thanks!
--
Fabien.
Hello Karl,
Another option would be to use "bytes bytea".
(The current patch uses "string bytea".)
This would probably also require some re-wording throughout.
Please let me know your preference.
I like it, but this is only my own limited opinion, and I'm not a native
English speaker.
Bonjour Michaël,
I don't follow what you mean by that.
The first versions of the patch did not change syntax_error(), and the
version committed has switched to use PQExpBufferData there. I think
that we should just do the same for the debug logs executing the meta
commands. This way, we get
Attached v3 shorten some lines and adds "append_tablespace".
A v4 which just extends the patch to newly added 'G'.
v5 is a rebase after 30a3e772.
--
Fabien.diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index ee1134aea2..9666c644b3 100644
--- a/src/bin/pgbench/pgbench.c
Patch v4 is a just a rebase.
Patch v5 is a rebase with some adjustements.
--
Fabien.diff --git a/src/bin/pgbench/Makefile b/src/bin/pgbench/Makefile
index f402fe7b91..e1d3ef9bb3 100644
--- a/src/bin/pgbench/Makefile
+++ b/src/bin/pgbench/Makefile
@@ -10,6 +10,7 @@ include $(top_builddir)/src/
Bonjour Michaël,
TBH, my recommendation would be to drop *all* of these likely()
and unlikely() calls. What evidence have you got that those are
meaningfully improving the quality of the generated code? And if
they're buried inside macros, they certainly aren't doing anything
useful in terms
Michaël,
So I think that the current situation is a good thing at least for debug.
If you look at some of my messages on other threads, you would likely
notice that my mood of the day is to not design things which try to
outsmart a user's expectations :)
I'm not following you.
ISTM that us
Patch applies and compiles.
Given that the paragraph begins with "Plain VACUUM (without FULL)", it is
better to have the VACUUM FULL explanations on a separate paragraph, and the
The original patch does that (Fabien agreed when I asked off list)
Indeed. I may have looked at it in reverse,
Hello Justin,
About this v4.
It applies cleanly.
I'm trying to think about how to get rid of the strange structure and
hacks, and the arbitrary looking size 2 array.
Also the recursion is one step, but I'm not sure why, ISTM it could/should
go on always?
Maybe the recursive implementati
Hello Justin,
I'm trying to think about how to get rid of the strange structure and hacks,
and the arbitrary looking size 2 array.
Also the recursion is one step, but I'm not sure why, ISTM it could/should
go on always?
Because tmpfiles only go one level deep.
I'm not sure it is a general
Hello Karl,
New patch attached: doc_base64_v13.patch
This required surprisingly little re-wording.
Added word "binary" into the descriptions of convert(),
substring(), convert_from(), and convert_to().
I also added data types to the call syntax of set_bit()
and set_byte().
And this patch add
Hello Tom,
This is one of the patches already marked as RFC (since September by
Alvaro). Anyone interested in actually pushing it, so that it does not
fall through to yet another commitfest?
TBH, I think we'd be better off to reject it. This makes a nontrivial
change in a very long-standing
My own vote would be to use the initial patch (after applying any
unrelated changes per later review), ie. add the feature with its
disable button.
I can do that, but not if there is a veto from Tom on the feature.
I wish definite negative opinions by senior committers would be expressed
ea
Hello,
+1 on the idea.
By quickly looking at the patch, I notice that there are no tests.
Is it possible to emulate somthing without the actual hardware, at least
for testing purposes?
--
Fabien.
Hello Vik,
I cannot ever think of a time when I don't want to know if I'm in a
transaction or not (and what its state is). Every new setup I do, I add
%x to the psql prompt.
I think it should be part of the default prompt. Path attached.
Isn't there examples in the documentation which use
Hello Vik,
Isn't there examples in the documentation which use the default prompts?
If so, should they be updated accordingly?
Good catch!
I thought about the documentation but not the examples therein.
Updated patch attached.
Ok.
Only one transaction prompt example in the whole document
Bonjour Michaël,
Maybe it should be -P X where X is the expected
delay in seconds. Pgbench progress reporting on initialization basically
outputs 10 rows per second, probably it is too much.
I cannot say for pgbench. I personally think that's a lot but you are
the one who wrote it as such I
For pg_checksums, probably some improvement patch will be submitted later,
if someone feels like it.
Let's see. I think that what we have now in v12 is good enough for
checksum operations on an offline cluster. And my take is that we
should focus more on online checksum verification for v13
Ah, so we now we can get rid of the TState * being passed around
separately for expression execution, too?
Indeed.
I would have thought that the compiler would have warned if it is unused,
but because of the recursion it is uselessly used.
Ok, maybe the sentence above is not very clear. At
Hello devs,
The attached patch adds minimal stats during the initialization phase.
Such a feature was already submitted by Doug Rady two years ago,
https://commitfest.postgresql.org/15/1308/
but it needed to be adapted to the -I custom initialization approach
developed in the same C
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
done in 0.68 s (drop 0.06 s, create table 0.02 s, generate 0.34 s, vacuum
0.13 s, primary keys 0.13 s).
See the durations on the last line.
It's even better with working TAP tests.
--
Fabien.diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index 99529de52a..76a5b87fe8 100
401 - 500 of 1351 matches
Mail list logo
