Re: A better way than tweaking NTUP_PER_BUCKET - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: A better way than tweaking NTUP_PER_BUCKET
Date
Msg-id CA+U5nMJsGwNV+Z8FMAcfNLJ30Ya-yKzhzZrVdjN+bY81gMX6dQ@mail.gmail.com
Whole thread Raw
In response to Re: A better way than tweaking NTUP_PER_BUCKET  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: A better way than tweaking NTUP_PER_BUCKET  (Jeremy Harris <jgh@wizmail.org>)
Re: A better way than tweaking NTUP_PER_BUCKET  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On 27 January 2014 17:44, Pavel Stehule <pavel.stehule@gmail.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.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe
Next
From: Heikki Linnakangas
Date:
Subject: Re: Failure while inserting parent tuple to B-tree is not fun