Re: [PROPOSAL] VACUUM Progress Checker.

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: [PROPOSAL] VACUUM Progress Checker.
Дата
Msg-id 55B27D49.3060909@BlueTreble.com
обсуждение исходный текст
Ответ на Re: [PROPOSAL] VACUUM Progress Checker.  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [PROPOSAL] VACUUM Progress Checker.  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: fdw_scan_tlist for foreign table scans breaks EPQ testing, doesn't it?
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [PROPOSAL] VACUUM Progress Checker.