On Wed, Aug 23, 2023 at 09:35:20AM -0700, Nathan Bossart wrote:
> On Tue, Aug 22, 2023 at 07:06:23AM -0700, Nathan Bossart wrote:
>> On Tue, Aug 22, 2023 at 11:49:33AM +0200, Peter Eisentraut wrote:
>>> Let's change MESSAGE_WIDTH to 62 in v16, and then pursue the larger
>>> restructuring leisurely.
On Tue, Aug 22, 2023 at 07:06:23AM -0700, Nathan Bossart wrote:
> On Tue, Aug 22, 2023 at 11:49:33AM +0200, Peter Eisentraut wrote:
>> Let's change MESSAGE_WIDTH to 62 in v16, and then pursue the larger
>> restructuring leisurely.
>
> Sounds good. I plan to commit this within the next couple of d
On Tue, Aug 22, 2023 at 11:49:33AM +0200, Peter Eisentraut wrote:
> Let's change MESSAGE_WIDTH to 62 in v16, and then pursue the larger
> restructuring leisurely.
Sounds good. I plan to commit this within the next couple of days.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On 01.08.23 17:45, Nathan Bossart wrote:
On Tue, Aug 01, 2023 at 09:46:02AM +0200, Peter Eisentraut wrote:
On 31.07.23 20:37, Nathan Bossart wrote:
- prep_status("Checking for incompatible \"aclitem\" data type in user
tables");
+ prep_status("Checking for \"aclitem\" data type in
On Wed, Aug 02, 2023 at 09:09:14AM -0700, Nathan Bossart wrote:
> On Wed, Aug 02, 2023 at 01:02:53PM +0530, Bharath Rupireddy wrote:
>> On Wed, Aug 2, 2023 at 12:45 PM Peter Eisentraut
>> wrote:
>>> I think we should change the output format to be more like initdb, like
>>>
>>> Doing somethi
On Wed, Aug 02, 2023 at 01:02:53PM +0530, Bharath Rupireddy wrote:
> On Wed, Aug 2, 2023 at 12:45 PM Peter Eisentraut wrote:
>> I think we should change the output format to be more like initdb, like
>>
>> Doing something ... ok
>>
>> without horizontally aligning all the "ok"s.
>
> While th
On Wed, Aug 02, 2023 at 09:14:06AM +0200, Peter Eisentraut wrote:
> On 01.08.23 18:00, Nathan Bossart wrote:
>> One of the main purposes of this thread is to gauge interest. I'm hoping
>> there are other developers who are interested in reducing
>> pg_upgrade-related downtime, and it seemed like i
On 02.08.23 10:30, Bharath Rupireddy wrote:
Moreover, the ts command gives me the timestamps for each
of the messages printed, so an extra step is required to calculate the
time taken for an operation.
There is "ts -i" for that.
On Wed, Aug 2, 2023 at 12:44 PM Peter Eisentraut wrote:
>
> On 01.08.23 18:00, Nathan Bossart wrote:
> > One of the main purposes of this thread is to gauge interest. I'm hoping
> > there are other developers who are interested in reducing
> > pg_upgrade-related downtime, and it seemed like it'd
On Wed, Aug 2, 2023 at 12:45 PM Peter Eisentraut wrote:
>
> On 01.08.23 17:45, Nathan Bossart wrote:
> > The message is too long, so there's no space between it and the "ok"
> > message:
> >
> > Checking for incompatible "aclitem" data type in user tablesok
> >
> > Instead of altering the me
On 01.08.23 17:45, Nathan Bossart wrote:
The message is too long, so there's no space between it and the "ok"
message:
Checking for incompatible "aclitem" data type in user tablesok
Instead of altering the messages, we could bump MESSAGE_WIDTH from 60 to
62 or 64. Do you prefer that ap
On 01.08.23 18:00, Nathan Bossart wrote:
One of the main purposes of this thread is to gauge interest. I'm hoping
there are other developers who are interested in reducing
pg_upgrade-related downtime, and it seemed like it'd be nice to have
built-in functionality for measuring the step times ins
On Tue, Aug 1, 2023 at 9:00 AM Nathan Bossart wrote:
> >> On 1 Aug 2023, at 09:45, Peter Eisentraut wrote:
> >> But who would use that, other than, you know, you, right now?
/me raises hand
Or at least, me back when I was hacking on pg_upgrade performance.
This, or something like it, would have
On Tue, Aug 01, 2023 at 09:58:24AM +0200, Daniel Gustafsson wrote:
>> On 1 Aug 2023, at 09:45, Peter Eisentraut wrote:
>> On 28.07.23 01:51, Nathan Bossart wrote:
>
>>> This information can be used to better understand where the time is going
>>> and to validate future improvements.
>>
>> But wh
On Tue, Aug 01, 2023 at 09:46:02AM +0200, Peter Eisentraut wrote:
> On 31.07.23 20:37, Nathan Bossart wrote:
>> -prep_status("Checking for incompatible \"aclitem\" data type in user
>> tables");
>> +prep_status("Checking for \"aclitem\" data type in user tables");
>
> Why these changes?
> On 1 Aug 2023, at 09:45, Peter Eisentraut wrote:
> On 28.07.23 01:51, Nathan Bossart wrote:
>> This information can be used to better understand where the time is going
>> and to validate future improvements.
>
> But who would use that, other than, you know, you, right now?
>
> I think the pg
On 31.07.23 20:37, Nathan Bossart wrote:
- prep_status("Checking for incompatible \"aclitem\" data type in user
tables");
+ prep_status("Checking for \"aclitem\" data type in user tables");
Why these changes? I think this is losing precision about what it's doing.
On 28.07.23 01:51, Nathan Bossart wrote:
I've been looking into some options for reducing the amount of downtime
required for pg_upgrade, and $SUBJECT seemed like something that would be
worthwhile independent of that effort. The attached work-in-progress patch
adds the elapsed time spent in eac
ar output_path[MAXPGPATH];
- prep_status("Checking for invalid \"sql_identifier\" user columns");
+ prep_status("Checking for \"sql_identifier\" data type in user tables");
snprintf(output_path, sizeof(output_path), "%s/%s",
log_opts.basedir,
--
2.25.1
>From 99ba19034
On Sun, Jul 30, 2023 at 2:44 AM Nathan Bossart wrote:
>
> On Sat, Jul 29, 2023 at 12:17:40PM +0530, Bharath Rupireddy wrote:
> > While on this, I noticed a thing unrelated to your patch that there's
> > no space between the longest status message of size 60 bytes and ok -
> > 'Checking for incompa
On Sat, Jul 29, 2023 at 12:17:40PM +0530, Bharath Rupireddy wrote:
> While on this, I noticed a thing unrelated to your patch that there's
> no space between the longest status message of size 60 bytes and ok -
> 'Checking for incompatible "aclitem" data type in user tablesok
> 23.932 ms'. I think
On Sat, Jul 29, 2023 at 12:17 AM Nathan Bossart
wrote:
>
> On Fri, Jul 28, 2023 at 10:38:14AM -0700, Nathan Bossart wrote:
> > I'm okay with simply adding the time. However, I wonder if we want to
> > switch to seconds, minutes, hours, etc. if the step takes longer. This
> > would add a bit of c
from PrintTiming() in
src/bin/psql/common.c).
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 6a4b836b33c3e18a57438044a10da95ec89dcb65 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Thu, 27 Jul 2023 16:16:45 -0700
Subject: [PATCH v2 1/1] add timing information to pg_upgr
On Fri, Jul 28, 2023 at 01:10:14PM +0530, Bharath Rupireddy wrote:
> How about using INSTR_TIME_SET_CURRENT, INSTR_TIME_SUBTRACT and
> INSTR_TIME_GET_MILLISEC macros instead of gettimeofday and explicit
> calculations?
That seems like a good idea.
> +report_status(PG_REPORT, "ok (took %ld ms)
On Fri, Jul 28, 2023 at 5:21 AM Nathan Bossart wrote:
>
> This information can be used to better understand where the time is going
> and to validate future improvements. I'm open to suggestions on formatting
> the timing information, assuming folks are interested in this idea.
>
> Thoughts?
+1
:00 2001
From: Nathan Bossart
Date: Thu, 27 Jul 2023 16:16:45 -0700
Subject: [PATCH v1 1/1] add timing information to pg_upgrade
---
src/bin/pg_upgrade/util.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/util.c b/src/bin/pg_upgrade
26 matches
Mail list logo
