Re: Performance tuning on RedHat Enterprise Linux 3
От | Tom Lane |
---|---|
Тема | Re: Performance tuning on RedHat Enterprise Linux 3 |
Дата | |
Msg-id | 10681.1102397719@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Performance tuning on RedHat Enterprise Linux 3 (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: Performance tuning on RedHat Enterprise Linux 3
Re: Performance tuning on RedHat Enterprise Linux 3 |
Список | pgsql-general |
Neil Conway <neilc@samurai.com> writes: > As a quick hack, what about throwing away the constructed hash table and > switching to hashing for sorting if we exceed sort_mem by a significant > factor? (say, 200%) We might also want to print a warning message to the > logs. If I thought that a 200% error in memory usage were cause for a Chinese fire drill, then I'd say "yeah, let's do that". The problem is that the place where performance actually goes into the toilet is normally an order of magnitude or two above the nominal sort_mem setting (for obvious reasons: admins can't afford to push the envelope on sort_mem because of the various unpredictable multiples that may apply). So switching to a hugely more expensive implementation as soon as we exceed some arbitrary limit is likely to be a net loss not a win. If you can think of a spill methodology that has a gentle degradation curve, then I'm all for that. But I doubt there are any quick-hack improvements to be had here. regards, tom lane
В списке pgsql-general по дате отправления: