On 2019-03-21 12:51, Christoph Berg wrote:
> Re: David Steele 2019-03-20
> <8a85bece-b18f-0433-acf3-d106b31f0...@pgmasters.net>
Oh, right. So the way to go would be to use _("FAILED "), and
ask translators to use the same length.
>>>
>>> Note there's no translation for pg_regress.
Re: David Steele 2019-03-20 <8a85bece-b18f-0433-acf3-d106b31f0...@pgmasters.net>
> > > Oh, right. So the way to go would be to use _("FAILED "), and
> > > ask translators to use the same length.
> >
> > Note there's no translation for pg_regress. All these _() markers are
> > currently
Hi Christophe,
On 3/8/19 5:12 PM, Alvaro Herrera wrote:
On 2019-Mar-08, Christoph Berg wrote:
Re: Peter Eisentraut 2019-03-08
<3eb194cf-b878-1f63-8623-6d6add0ed...@2ndquadrant.com>
On 2019-02-21 10:37, Christoph Berg wrote:
diff --git a/src/test/regress/pg_regress.c
On 2019-Mar-08, Christoph Berg wrote:
> Re: Peter Eisentraut 2019-03-08
> <3eb194cf-b878-1f63-8623-6d6add0ed...@2ndquadrant.com>
> > On 2019-02-21 10:37, Christoph Berg wrote:
> > > diff --git a/src/test/regress/pg_regress.c b/src/test/regress/pg_regress.c
> > > index a18a6f6c45..8080626e94
Re: Peter Eisentraut 2019-03-08
<3eb194cf-b878-1f63-8623-6d6add0ed...@2ndquadrant.com>
> On 2019-02-21 10:37, Christoph Berg wrote:
> > diff --git a/src/test/regress/pg_regress.c b/src/test/regress/pg_regress.c
> > index a18a6f6c45..8080626e94 100644
> > --- a/src/test/regress/pg_regress.c
> >
On 2019-02-21 10:37, Christoph Berg wrote:
> diff --git a/src/test/regress/pg_regress.c b/src/test/regress/pg_regress.c
> index a18a6f6c45..8080626e94 100644
> --- a/src/test/regress/pg_regress.c
> +++ b/src/test/regress/pg_regress.c
> @@ -1794,12 +1794,14 @@ run_schedule(const char *schedule,
Re: Tom Lane 2019-02-18 <28360.1550506...@sss.pgh.pa.us>
> >>> We should also strive to align "FAILED" properly.
>
> >> Yeah, not strictly required, but someone might want to play around with
> >> it a bit.
>
> > FWIW I don't think we localize pg_regress output currently, so that
> > argument
Alvaro Herrera writes:
> On 2019-Feb-18, Peter Eisentraut wrote:
>>> We should also strive to align "FAILED" properly.
>> Yeah, not strictly required, but someone might want to play around with
>> it a bit.
> FWIW I don't think we localize pg_regress output currently, so that
> argument seems
On 2019-Feb-18, Peter Eisentraut wrote:
> On 2019-02-15 15:54, Tom Lane wrote:
> >> We should also strive to align "FAILED" properly.
> > Hmm. The reasonable ways to accomplish that look to be either
> > (a) pad "ok" to the width of "FAILED", or (b) rely on emitting a tab.
> > I don't much like
On 2019-02-15 15:54, Tom Lane wrote:
>> We should also strive to align "FAILED" properly.
> Hmm. The reasonable ways to accomplish that look to be either
> (a) pad "ok" to the width of "FAILED", or (b) rely on emitting a tab.
> I don't much like either, especially from the localization angle.
>
John Naylor writes:
> On 2/15/19, Peter Eisentraut wrote:
>> We should also strive to align "FAILED" properly. This is currently
>> quite unreadable:
>>
>> int4 ... ok (128 ms)
>> int8 ... FAILED (153 ms)
>> oid ... ok
Peter Eisentraut writes:
> If we're going to keep this, should we enable the prove --timer option as
> well?
As far as that goes: I've found that in some of my older Perl
installations, prove doesn't recognize the --timer switch.
So turning that on would require a configuration probe of some
On 2/15/19, Peter Eisentraut wrote:
> We should also strive to align "FAILED" properly. This is currently
> quite unreadable:
>
> int4 ... ok (128 ms)
> int8 ... FAILED (153 ms)
> oid ... ok (163 ms)
>
Peter Eisentraut writes:
> On 2019-02-15 14:32, Peter Eisentraut wrote:
>> test event_trigger... ok 128 ms
>> test fast_default ... ok 173 ms
>> test stats... ok 637 ms
That looks reasonable, although on machines where test
On 2019-02-15 14:32, Peter Eisentraut wrote:
> identity ... ok 238 ms
> partition_join ... ok 429 ms
> partition_prune ... ok 786 ms
> reloptions ... ok 94 ms
> hash_part
On 2019-02-11 15:30, Tom Lane wrote:
> Peter Eisentraut writes:
>> Now that I see this in action, it makes the actual test results harder
>> to identify flying by. I understand the desire to collect this timing
>> data, but that is a special use case and not relevant to the normal use
>> of the
On Tue, Feb 12, 2019 at 10:29:40AM +0900, Amit Langote wrote:
> On 2019/02/11 23:30, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> Now that I see this in action, it makes the actual test results harder
>>> to identify flying by. I understand the desire to collect this timing
>>> data, but that
On 2019/02/11 23:30, Tom Lane wrote:
> Peter Eisentraut writes:
>> Now that I see this in action, it makes the actual test results harder
>> to identify flying by. I understand the desire to collect this timing
>> data, but that is a special use case and not relevant to the normal use
>> of the
Peter Eisentraut writes:
> Now that I see this in action, it makes the actual test results harder
> to identify flying by. I understand the desire to collect this timing
> data, but that is a special use case and not relevant to the normal use
> of the test suite, which is to see whether the
On 10/02/2019 22:55, Tom Lane wrote:
> Daniel Gustafsson writes:
>>> On 10 Feb 2019, at 04:50, Tom Lane wrote:
>>> Does anyone else feel that this is interesting/useful data?
>
>> Absolutely, +1 on this. In Greenplum we print the runtime of the script and
>> the runtime of the diff, both of
Daniel Gustafsson writes:
>> On 10 Feb 2019, at 04:50, Tom Lane wrote:
>> Does anyone else feel that this is interesting/useful data?
> Absolutely, +1 on this. In Greenplum we print the runtime of the script and
> the runtime of the diff, both of which have provided useful feedback on where
>
> On 10 Feb 2019, at 04:50, Tom Lane wrote:
> Does anyone else feel that this is interesting/useful data?
Absolutely, +1 on this. In Greenplum we print the runtime of the script and
the runtime of the diff, both of which have provided useful feedback on where
to best spend optimization efforts
Hi,
On February 10, 2019 9:20:18 AM GMT+05:30, Tom Lane wrote:
>I've wondered for some time whether we couldn't make a useful
>reduction in the run time of the PG regression tests by looking
>for scripts that run significantly longer than others in their
>parallel groups, and making an effort to
On Sat, Feb 9, 2019 at 7:50 PM Tom Lane wrote:
> I've wondered for some time whether we couldn't make a useful
> reduction in the run time of the PG regression tests by looking
> for scripts that run significantly longer than others in their
> parallel groups, and making an effort to trim the
I've wondered for some time whether we couldn't make a useful
reduction in the run time of the PG regression tests by looking
for scripts that run significantly longer than others in their
parallel groups, and making an effort to trim the runtimes of
those particular scripts.
The first step in
25 matches
Mail list logo
