Re: [PROPOSAL] VACUUM Progress Checker. - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: [PROPOSAL] VACUUM Progress Checker.
Date
Msg-id 55B27D49.3060909@BlueTreble.com
Whole thread Raw
In response to Re: [PROPOSAL] VACUUM Progress Checker.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [PROPOSAL] VACUUM Progress Checker.  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 7/23/15 2:43 PM, Robert Haas wrote:
> On Wed, Jul 22, 2015 at 11:28 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>> If we want to expose that level of detail, I think either JSON or arrays
>> would make more sense, so we're not stuck with a limited amount of info.
>> Perhaps DDL would be OK with the numbers you suggested, but
>> https://www.pgcon.org/2013/schedule/events/576.en.html would not, and I
>> think wanting query progress is much more common.
>
> You need to restrict the amount of info, because you've got to
> preallocate enough shared memory to store all the data that somebody
> might report.

I was thinking your DSM stuff would come into play here. We wouldn't 
want to be reallocating during execution, but I'd expect we would know 
during setup how much memory we actually needed.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: fdw_scan_tlist for foreign table scans breaks EPQ testing, doesn't it?
Next
From: Robert Haas
Date:
Subject: Re: [PROPOSAL] VACUUM Progress Checker.