On Mon, Jul 4, 2016 at 1:06 AM, Marko Tiikkaja wrote:
> Hi,
>
> Here's a patch for $SUBJECT. I'll probably work on the docs a bit more
> before the next CF, but I thought I'd post it anyway.
>
I could see that it can be useful in certain cases as described in the
documentation part of the patch.
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 (0.012345s)
Time: 1234.567 ms (1.235s)
T
> "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: 98765.432 ms (98.8s)
Time: 123456.
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, you
>> might get output like this:
>> Time: 1234567.
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:
http://www.postgresql.org/mailpref/
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 nowadays is using the log_checkp
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 nowa
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 cont
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 to
>>> Working Group". Is that h
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
>> is indeed broken, $target can be a full path, and if it contains a
>> space things blow up. The commands of vcregress upgrade
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 ma
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 phrasing of the problem is that after a long query, you
> >> might get output like
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 like this:
> > Time: 1234567.666 ms
> > which is pretty
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:
http://www.postgresql.org/mailpref/pgsql-hackers
> "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:
>> Time: 1234567.666 ms
>> which is pretty useless.
T
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 that is that not infrequently, I'l
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 on/off
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 proposing might as well be the default and
> > only form
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 (pgsql-hackers@postgresql.org)
To make chang
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 you're trying to do arithmetic on t
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 starttli
from
> > > the ControlFile structure, but it w
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 Developm
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 feedback"?
>> ISO/IEC PDTR 19075-5 (Row
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
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 makes sense from a client
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:
SE
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 store results of
> prece
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.
--
Fabien.dif
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 reus
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
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 mailin
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 noop
32 matches
Mail list logo
