[HACKERS] pgbench - minor doc improvements

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

Re: [HACKERS] pgbench - allow to store select results into variables

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:

[HACKERS] pgbench - allow to store select results into variables

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

Re: [HACKERS] [BUGS] BUG #14230: Wrong timeline returned by pg_stop_backup on a standby

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

Re: [HACKERS] pgbench more operators & functions

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

Re: [HACKERS] pgbench - allow to store select results into variables

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

[HACKERS] pgbench - minor fix for meta command only scripts

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

[HACKERS] pgbench - allow empty queries

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

[HACKERS] pgbench - compute & show latency consistently

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. --

Re: [HACKERS] pgbench - allow to store select results into variables

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

Re: [HACKERS] \timing interval

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

Re: [HACKERS] \timing interval

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

Re: [HACKERS] \timing interval

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:

Re: [HACKERS] \timing interval

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

Re: [HACKERS] \timing interval

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

Re: [HACKERS] \timing interval

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

Re: [HACKERS] \timing interval

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

Re: [HACKERS] \timing interval

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

Re: [HACKERS] \timing interval

> "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:

Re: [HACKERS] [BUGS] BUG #14230: Wrong timeline returned by pg_stop_backup on a standby

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

Re: [HACKERS] Forthcoming SQL standards about JSON and Multi-Dimensional Arrays (FYI)

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

Re: [HACKERS] \timing interval

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

Re: [HACKERS] pgbench - allow to store select results into variables

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

Re: [HACKERS] [CF2016-9] Allow spaces in working path on tap-tests

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

Re: [HACKERS] \timing interval

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

Re: [HACKERS] remove checkpoint_warning

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

Re: [HACKERS] remove checkpoint_warning

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

Re: [HACKERS] \timing interval

> "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:

Re: [HACKERS] \timing interval

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,

Re: [HACKERS] \timing interval

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

[HACKERS] remove checkpoint_warning

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

Re: [HACKERS] Forthcoming SQL standards about JSON and Multi-Dimensional Arrays (FYI)

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

Re: [HACKERS] \timing interval

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: