Re: things I learned from working on memory allocation
От | Peter Geoghegan |
---|---|
Тема | Re: things I learned from working on memory allocation |
Дата | |
Msg-id | CAM3SWZRmuSNukqLqJHw8b3biArnK=xV3czZJGdr2B-9Z-a_Z1g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: things I learned from working on memory allocation (Peter Geoghegan <pg@heroku.com>) |
Список | pgsql-hackers |
On Mon, Jul 7, 2014 at 7:29 PM, Peter Geoghegan <pg@heroku.com> wrote: >> I do think that's a problem with our sort implementation, but it's not >> clear to me whether it's *more* of a problem for parallel sort than it >> is for single-backend sort. > > If you'll forgive me for going on about my patch on this thread, I > think the pgbench "-c 4" and "-c 1" cases that I tested suggest it is > a particular problem for parallel sorts, as there is a much bigger > both absolute and proportional difference in transaction throughput > between those two with the patch applied. It seems reasonable to > suppose the difference would be larger still if we were considering a > single parallel sort, as opposed to multiple independent sorts (of the > same data) that happen to occur in parallel. I think that I may have been too optimistic when I said that there was an apparent trend of memory bandwidth per core merely stagnating: http://users.ece.cmu.edu/~omutlu/pub/mutlu_memory-scaling_imw13_invited-talk.pdf As slide 8 indicates, memory capacity per core is expected to go down 30% every two years, while the trend for memory bandwidth per core is even worse. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: