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
|
Список | 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 по дате отправления: