Re: not exactly a bug report, but surprising behaviour
От | Tom Lane |
---|---|
Тема | Re: not exactly a bug report, but surprising behaviour |
Дата | |
Msg-id | 22981.1044430472@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: not exactly a bug report, but surprising behaviour (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: not exactly a bug report, but surprising behaviour
|
Список | pgsql-general |
Greg Stark <gsstark@mit.edu> writes: > I'm watching this query I'm working on now drive the cpu to 100% for 6+ hours > with virtually no I/O. And I think it's the best I can do. All the times is > being spent moving bits around from one place to another. It would be interesting to see a gprof profile of that. > It occurs to me that it's possible postgres is doing this already at a lower > level of abstraction. Yes, tuplesort.c has heard of pushing pointers around rather than copying records. I wonder though whether data is being pushed out to kernel disk buffers and then back in again --- do you have sort_mem set large enough? Another likely theory is that the interface layers needed to access datatype-specific comparison routines are chewing the cycles. Need facts not speculation to know where the bottleneck is... regards, tom lane
В списке pgsql-general по дате отправления: