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