| From: | Jeremy Harris <jgh(at)wizmail(dot)org> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: A better way than tweaking NTUP_PER_BUCKET |
| Date: | 2014-01-28 10:32:51 |
| Message-ID: | 52E78753.90103@wizmail.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 27/01/14 18:00, Simon Riggs wrote:
> On 27 January 2014 17:44, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>
>> This topic is interesting - we found very bad performance with hashing large
>> tables with high work_mem. MergeJoin with quicksort was significantly
>> faster.
>
> I've seen this also.
>
>> I didn't deeper research - there is a possibility of virtualization
>> overhead.
>
> I took measurements and the effect was repeatable and happened for all
> sizes of work_mem, but nothing more to add.
FWIW my current list-based internal merge seems to perform worse at
larger work-mem, compared to quicksort. I've been starting to wonder
if the rate of new ram-chip page opens is an issue (along with the
more-usually considered cache effects). Any random-access workload
would be affected by this, if it really exists.
--
Cheers,
Jeremy
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marti Raudsepp | 2014-01-28 10:36:54 | Re: PoC: Partial sort |
| Previous Message | Craig Ringer | 2014-01-28 10:27:40 | Re: Infinite recursion in row-security based on updatable s.b. views |