Re: [COMMITTERS] pgsql: Teach tuplesort.c about "top N" sorting, in which only the first

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: [COMMITTERS] pgsql: Teach tuplesort.c about "top N" sorting, in which only the first
Дата
Msg-id ED48CE35-22B1-421C-8956-81EBD50AA45C@decibel.org
обсуждение исходный текст
Ответ на Re: [COMMITTERS] pgsql: Teach tuplesort.c about "top N" sorting, in which only the first  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [COMMITTERS] pgsql: Teach tuplesort.c about "top N" sorting, in which only the first  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
On May 6, 2007, at 9:32 AM, Tom Lane wrote:
> Jim Nasby <decibel@decibel.org> writes:
>> There's several problems with that. First, trace_sort isn't
>> documented (or at least it's not in postgresql.conf), so most folks
>> don't know it exists. Second, in order to see it's output you have to
>> drop log_min_messages to debug. That results in a huge log volume,
>> especially on a production system.
>
> Nonsense ... trace_sort output is at LOG level.

I stand corrected. But my point still remains. It wouldn't be unusual  
for a website database to be running several sorts a second; that  
means 4 lines per sort, which is still a large amount of data.

If we really want to make the logfile the approved method for  
monitoring performance, then why do we have the stats infrastructure  
at all? It could all be replaced with logging output and pgfouine.

Why are we maintaining two separate sets of code for monitoring  
database performance?
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)




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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: plperl vs. bytea
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Managing the community information stream