Re: bad estimation together with large work_mem generates terrible slow hash joins

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Kevin Grittner <kgrittn(at)ymail(dot)com>, Tomas Vondra <tv(at)fuzzy(dot)cz>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bad estimation together with large work_mem generates terrible slow hash joins
Date: 2014-10-02 07:11:21
Message-ID: 542CFA99.9070003@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/02/2014 03:20 AM, Kevin Grittner wrote:
> My only concern from the benchmarks is that it seemed like there
> was a statistically significant increase in planning time:
>
> unpatched plan time average: 0.450 ms
> patched plan time average: 0.536 ms
>
> That *might* just be noise, but it seems likely to be real. For
> the improvement in run time, I'd put up with an extra 86us in
> planning time per hash join; but if there's any way to shave some
> of that off, all the better.

The patch doesn't modify the planner at all, so it would be rather
surprising if it increased planning time. I'm willing to just write that
off as noise.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2014-10-02 07:50:21 Re: bad estimation together with large work_mem generates terrible slow hash joins
Previous Message Heikki Linnakangas 2014-10-02 07:07:45 Re: UPSERT wiki page, and SQL MERGE syntax