Re: Performance tuning on RedHat Enterprise Linux 3

Поиск
Список
Период
Сортировка
От Paul Tillotson
Тема Re: Performance tuning on RedHat Enterprise Linux 3
Дата
Msg-id 41B4E236.7010901@shentel.net
обсуждение исходный текст
Ответ на Re: Performance tuning on RedHat Enterprise Linux 3  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Ответы Re: Performance tuning on RedHat Enterprise Linux 3
Список pgsql-general
Alvaro Herrera wrote:

>On Tue, Dec 07, 2004 at 12:02:13PM +1100, Neil Conway wrote:
>
>
>>On Mon, 2004-12-06 at 19:37 -0500, Paul Tillotson wrote:
>>
>>
>>>I seem to remember hearing that the memory limit on certain operations,
>>>such as sorts, is not "enforced" (may the hackers correct me if I am
>>>wrong); rather, the planner estimates how much a sort might take by
>>>looking at the statistics for a table.
>>>
>>>
>
>
>
>>AFAIK this is not the case.
>>
>>
>
>AFAIK this is indeed the case with hashed aggregation, which uses the
>sort_mem (work_mem) parameter to control its operation, but for which it
>is not a hard limit.
>
>I concur however that multiple concurrent sorts may consume more memory
>than the limit specified for one sort.  (Just last week I saw a server
>running with sort_mem set to 800 MB ... no wonder the server went belly
>up every day at 3.00am, exactly when a lot of reports were being
>generated)
>
>
Does postgres actually do multiple concurrent sorts within a single
backend?  I didn't think it would ever do this, since each backend has
only a single thread.  David says that he sees a particular process
start to consume very large amounts of memory, and from my understanding
of postgres, this must be one single query taking a lot of memory, not
"multiple concurrent sorts."

Paul Tillotson

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

Предыдущее
От: Michael Fuhr
Дата:
Сообщение: Re: Detecting Temporary Tables
Следующее
От: Christopher Browne
Дата:
Сообщение: Re: Index bloat in 7.2