| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(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:03:38 |
| Message-ID: | CA+TgmoZHb6n6WRDMjTXusp_fAptsx5Dyj0nuSr7XfK-xV+RAeA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jul 24, 2015 at 2:00 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
>> 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.
You could make that work, but it would be a pretty significant amount
of new mechanism. Also, if it's to be practical to report progress
frequently, it's got to be cheap, and that precludes reporting vast
volumes of data.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2015-07-24 18:06:56 | Re: [PROPOSAL] VACUUM Progress Checker. |
| Previous Message | Jim Nasby | 2015-07-24 18:00:41 | Re: [PROPOSAL] VACUUM Progress Checker. |