| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Rahila Syed <rahilasyed90(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PROPOSAL] VACUUM Progress Checker. |
| Date: | 2015-07-24 18:00:41 |
| Message-ID: | 55B27D49.3060909@BlueTreble.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 7/23/15 2:43 PM, Robert Haas wrote:
> On Wed, Jul 22, 2015 at 11:28 AM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2015-07-24 18:03:38 | Re: [PROPOSAL] VACUUM Progress Checker. |
| Previous Message | Robert Haas | 2015-07-24 17:58:42 | Re: fdw_scan_tlist for foreign table scans breaks EPQ testing, doesn't it? |