Minor pgbench documentation improvements so that the description is more
precise:
- a pgbench script may not contain SQL commands, it only needs not to be
empty.
- point out explicitely variable setting meta commands.
- the formula is short enough to fit on a line.
--
Fabien.diff --git
Hello Pavel,
Why you are introducing \into and not \gset like psql does?
Good question.
The \into syntax I implemented is more generic, you can send a bunch of
queries together and extract the results, which makes sense from a client
perspective where reducing latency is important:
Hello devs,
I mentionned my intention to add some features to pgbench back in March:
https://www.postgresql.org/message-id/alpine.DEB.2.10.1603301618570.5677@sto
The attached patch adds an \into meta command to store results of
preceding SELECTs into pgbench variables, so that they can be
On Thu, Jul 7, 2016 at 12:08 PM, Michael Paquier
wrote:
> On Thu, Jul 7, 2016 at 12:57 AM, Marco Nenciarini
> wrote:
>> After further analysis, the issue is that we retrieve the starttli from
>> the ControlFile structure, but it was
Here is a simple patch which adds a bunch of operators (bitwise: & | ^ ~,
comparisons: =/== <>/!= < <= > >=, logical: and/&& or/|| xor/^^ not/!) and
functions (exp ln if) to pgbench. I've tried to be pg's SQL compatible where
appropriate.
Also attached is a simple test script.
Here is a
2016-07-09 11:19 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> Why you are introducing \into and not \gset like psql does?
>>
>
> Good question.
>
> The \into syntax I implemented is more generic, you can send a bunch of
> queries together and extract the results, which
While testing meta-command pgbench only scripts, I noticed that there is
an infinite loop in threadRun, which means that other tasks such as
reporting progress do not get a chance.
The attached patch breaks this loop by always returning at the end of a
script.
On "pgbench -T 3 -P 1 -f
I wanted to test overheads on an empty query, but pgbench does not allow
it. I do not see why not.
The attached very minor patch allows empty queries.
--
Fabien.
pgbench-empty-query-1.sql
Description: application/sql
empty.sql
Description: application/sql
--
Sent via pgsql-hackers
Currently the latency is not computed and displayed consistently:
- the computation is wrong under -t (duration is zero...)
- depending on the conditions it is shown with a ":" syntax or
a "=" syntax.
The attached minor patch makes the computation & display more consistent.
--
Hi
2016-07-09 10:20 GMT+02:00 Fabien COELHO :
>
> Hello devs,
>
> I mentionned my intention to add some features to pgbench back in March:
>
> https://www.postgresql.org/message-id/alpine.DEB.2.10.1603301618570.5677@sto
>
> The attached patch adds an \into meta command to
2016-07-09 18:59 GMT+02:00 Tom Lane :
> Peter Eisentraut writes:
> > On 7/7/16 5:52 PM, Corey Huinker wrote:
> >> Wouldn't it be great if we had a way of printing timing in more human
> >> friendly formats?
>
> > Something like what you are
On 7/9/16 12:59 PM, Tom Lane wrote:
NAK --- if you're trying to do arithmetic on the numbers, converting
them to hh:mm:ss notation isn't the best first step. I think a separate
setting somewhere to select the format would be good. Please *don't*
do "\timing interval" as that confuses the
Andrew Gierth writes:
> How about
> Time: 1234567.666 ms (20m 34.6s)
Hmm ... worksforme.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Sat, Jul 9, 2016 at 3:35 PM, Tom Lane wrote:
> Peter Eisentraut writes:
> > I'm not quite sure what you mean by wanting to do arithmetic on the
> > numbers. My phrasing of the problem is that after a long query, you
> > might get output
On Sat, Jul 9, 2016 at 4:00 PM, Andrew Gierth
wrote:
> > "Tom" == Tom Lane writes:
>
> > Peter Eisentraut writes:
> >> I'm not quite sure what you mean by wanting to do arithmetic on the
> >> numbers. My
Peter Eisentraut writes:
> On 7/7/16 5:52 PM, Corey Huinker wrote:
>> Wouldn't it be great if we had a way of printing timing in more human
>> friendly formats?
> Something like what you are proposing might as well be the default and
> only format.
NAK --- if
On Sat, Jul 9, 2016 at 5:59 PM, Tom Lane wrote:
> Also, might I suggest that leading zeroes in such a format are not
> helpful? That is, I'd want to see "1:02.345" not "00:01:02.345".
Or 1m 2s 345ms
--
greg
--
Sent via pgsql-hackers mailing list
Peter Eisentraut writes:
> I'm not quite sure what you mean by wanting to do arithmetic on the
> numbers. My phrasing of the problem is that after a long query, you
> might get output like this:
> Time: 1234567.666 ms
> which is pretty useless.
What I mean by
> "Tom" == Tom Lane writes:
> Peter Eisentraut writes:
>> I'm not quite sure what you mean by wanting to do arithmetic on the
>> numbers. My phrasing of the problem is that after a long query, you
>> might get output like this:
On Jul 9, 2016 4:52 AM, "Noah Misch" wrote:
>
> On Thu, Jul 07, 2016 at 03:38:26PM +0900, Michael Paquier wrote:
> > On Thu, Jul 7, 2016 at 12:57 AM, Marco Nenciarini
> > wrote:
> > > After further analysis, the issue is that we retrieve the
Hi Peter, hi all,
I wrote 2016-07-06 13:19 GMT+02:00:
> ...
> 2016-07-04 6:44 GMT+02:00 Thomas Munro :
>> ... But ISO/IEC CD 9075-15
>> (Multi-Dimensional Arrays) is in stage 30.92 "CD referred back to
>> Working Group". Is that how they say "returned with
On 7/7/16 5:52 PM, Corey Huinker wrote:
Wouldn't it be great if we had a way of printing timing in more human
friendly formats?
Something like what you are proposing might as well be the default and
only format.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL
Also a more subjective argument: I do not like the gset automagic naming
feature. I got more inspired by PL/pgSQL and ECPG which both have an "into"
syntax with explicit variable names that let nothing to guessing. I like
things to be simple and explicit, hence the proposed into.
the gset was
Kyotaro HORIGUCHI writes:
> At Tue, 5 Jul 2016 13:44:08 +0900, Michael Paquier
> wrote in
>
>> Attached is the patch I have in mind. After more investigation zic.exe
Andrew Gierth wrote:
> How about
>
> Time: 1234567.666 ms (20m 34.6s)
>
> ?
+1 LGTM
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On 2016-07-09 16:46:32 -0400, Alvaro Herrera wrote:
> the checkpoint_warning feature was added by commit 2986aa6a668bce3cfb836
> in November 2002 when we didn't have any logging of checkpointing at
> all. I propose to remove it: surely anyone who cares about analyzing
> checkpointing behavior
Alvaro Herrera writes:
> the checkpoint_warning feature was added by commit 2986aa6a668bce3cfb836
> in November 2002 when we didn't have any logging of checkpointing at
> all. I propose to remove it: surely anyone who cares about analyzing
> checkpointing behavior
> "Gavin" == Gavin Flower writes:
>> How about
>>
>> Time: 1234567.666 ms (20m 34.6s)
Gavin> I like that, but I think the human form should retain the 3
Gavin> decimal places.
Scale it.
Time: 12.345 ms (0.012345s)
Time: 1234.567 ms (1.235s)
Time:
On 10/07/16 08:00, Andrew Gierth wrote:
"Tom" == Tom Lane writes:
> Peter Eisentraut writes:
>> I'm not quite sure what you mean by wanting to do arithmetic on the
>> numbers. My phrasing of the problem is that after a long query,
On 10/07/16 12:08, Andrew Gierth wrote:
"Gavin" == Gavin Flower writes:
>> How about
>>
>> Time: 1234567.666 ms (20m 34.6s)
Gavin> I like that, but I think the human form should retain the 3
Gavin> decimal places.
Scale it.
Time: 12.345 ms
the checkpoint_warning feature was added by commit 2986aa6a668bce3cfb836
in November 2002 when we didn't have any logging of checkpointing at
all. I propose to remove it: surely anyone who cares about analyzing
checkpointing behavior nowadays is using the log_checkpoint feature
instead, which
Hi Stefan,
On 07/09/2016 04:03 PM, Stefan Keller wrote:
> Hi Peter, hi all,
>
> I wrote 2016-07-06 13:19 GMT+02:00:
>> ...
>> 2016-07-04 6:44 GMT+02:00 Thomas Munro :
>>> ... But ISO/IEC CD 9075-15
>>> (Multi-Dimensional Arrays) is in stage 30.92 "CD referred back
On Sat, Jul 9, 2016 at 1:48 PM, Alvaro Herrera wrote:
>> How about
>>
>> Time: 1234567.666 ms (20m 34.6s)
>>
>> ?
>
> +1 LGTM
+1
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
33 matches
Mail list logo