From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: things I learned from working on memory allocation |
Date: | 2014-07-10 00:20:14 |
Message-ID: | CAM3SWZRmuSNukqLqJHw8b3biArnK=xV3czZJGdr2B-9Z-a_Z1g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jul 7, 2014 at 7:29 PM, Peter Geoghegan <pg(at)heroku(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-07-10 00:52:23 | Re: IMPORT FOREIGN SCHEMA statement |
Previous Message | Tom Lane | 2014-07-09 23:37:00 | Re: IMPORT FOREIGN SCHEMA statement |