Re: [HACKERS] vacuum process size

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] vacuum process size
Дата
Msg-id 2107.935507128@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] vacuum process size  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Ответы Re: [HACKERS] vacuum process size  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] vacuum process size  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Список pgsql-hackers
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> I have tested your idea and found even more improved memory usage
> (86MB vs. 43MB). Standard vacuum consumes as much as 478MB memory with
> deleting 5000000 tuples that would not be acceptable for most
> configurations. I think we should fix this as soon as possible.  If
> there's no objection, I will commit included patches to the stable
> tree (seems Tom has more aggressive idea, so I'll leave the current
> tree as it is).

No, please make the change in current as well.  I was thinking about
tweaking aset.c to be smarter about releasing large chunks, but in any
case having the doubling behavior at the request point will be a big
improvement.

I do not like your patch as given, however.  By using a static variable
you are assuming that there is only one active VPageList at a time.
It looks to me like there are at least two --- and there is no reason
to think they'd be the same size.

You need to add a num_pages field to the VPageList struct, not use
a static.
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Sorting costs (was Caution: tonight's commits force initdb)
Следующее
От: Theo Kramer
Дата:
Сообщение: Re: AW: [HACKERS] Caution: tonight's commits force initdb