From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Francisco Olarte <folarte(at)peoplecall(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Question / requests. |
Date: | 2016-10-07 13:20:23 |
Message-ID: | CA+TgmoawgaXsR-i-G+VVdRtQFUokYxANhRYERckiGYRsZ7kSLQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 5, 2016 at 10:58 AM, Francisco Olarte
<folarte(at)peoplecall(dot)com> wrote:
> On Tue, Oct 4, 2016 at 7:50 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Mon, Oct 3, 2016 at 5:44 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> ...
>>> I wonder if the real answer isn't just to disallow -f with parallel
>>> vacuuming.
>> Seems like we should figure out which catalog tables are needed in
>> order to perform a VACUUM, and force those to be done last and one at
>> a time.
>
> Is the system catalog a bottleneck for people who has real use for
> paralell vacuum?
I don't know, but it seems like the documentation for vacuumdb
currently says, more or less, "Hey, if you use -j with -f, it may not
work!", which seems unacceptable to me. It should be the job of the
person writing the feature to make it work in all cases, not the job
of the person using the feature to work around the problem when it
doesn't.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-10-07 13:23:55 | Re: Move allocation size overflow handling to MemoryContextAllocExtended()? |
Previous Message | Robert Haas | 2016-10-07 13:14:37 | Re: VACUUM's ancillary tasks |