Re: Vacuum: allow usage of more than 1GB of work mem

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Vacuum: allow usage of more than 1GB of work mem
Дата
Msg-id 13907.1473188354@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Vacuum: allow usage of more than 1GB of work mem  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: Vacuum: allow usage of more than 1GB of work mem  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> On 6 September 2016 at 19:23, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Tue, Sep 6, 2016 at 2:16 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> What occurs to me is that we can exactly predict how many tuples we
>>> are going to get when we autovacuum, since we measure that and we know
>>> what the number is when we trigger it.
>>> So there doesn't need to be any guessing going on at all, nor do we
>>> need it to be flexible.

>> No, that's not really true.  A lot can change between the time it's
>> triggered and the time it happens, or even while it's happening.
>> Somebody can run a gigantic bulk delete just after we start the
>> VACUUM.

> Which wouldn't be removed by the VACUUM, so can be ignored.

(1) If the delete commits just before the vacuum starts, it may be
removable.  I think you're nuts to imagine there are no race conditions
here.

(2) Stats from the stats collector never have been, and likely never will
be, anything but approximate.  That goes double for dead-tuple counts,
which are inaccurate even as sent from backends, never mind the multiple
ways that the collector might lose the counts.

The idea of looking to the stats to *guess* about how many tuples are
removable doesn't seem bad at all.  But imagining that that's going to be
exact is folly of the first magnitude.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: [GENERAL] C++ port of Postgres
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Quorum commit for multiple synchronous replication.