Re: tweaking NTUP_PER_BUCKET

From: Tomas Vondra <tv(at)fuzzy(dot)cz>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: tweaking NTUP_PER_BUCKET
Date: 2014-07-19 18:28:48
Message-ID: 53CAB8E0.2070502@fuzzy.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 19.7.2014 20:24, Tom Lane wrote:
> Tomas Vondra <tv(at)fuzzy(dot)cz> writes:
>> I've reviewed the two test cases mentioned here, and sadly there's
>> nothing that can be 'fixed' by this patch. The problem here lies in the
>> planning stage, which decides to hash the large table - we can't fix
>> that in the executor.
>
> We've heard a couple reports before of the planner deciding to hash a
> larger table rather than a smaller one. The only reason I can think of
> for that is if the smaller table has many more duplicates, so that the
> planner thinks the executor might end up traversing long hash chains.
> The planner's estimates could easily be off in this area, of course.
> estimate_hash_bucketsize() is the likely culprit if it's wrong.
>
> Which test case are you seeing this in, exactly?

The two reported by Stephen here:

http://www.postgresql.org/message-id/20130328235627.GV4361@tamriel.snowman.net

Just download this (I had to gunzip it):

http://snowman.net/~sfrost/test_case.sql
http://snowman.net/~sfrost/test_case2.sql

regards
Tomas

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Cochran 2014-07-19 18:30:45 Re: Proposal for updating src/timezone
Previous Message Tomas Vondra 2014-07-19 18:24:08 Re: tweaking NTUP_PER_BUCKET