Re: add_path optimization

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: add_path optimization
Date: 2009-02-01 19:13:15
Message-ID: 603c8f070902011113x1d979c3yd7a0f0476f52c227@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Feb 1, 2009 at 1:34 PM, Jaime Casanova
<jcasanov(at)systemguards(dot)com(dot)ec> wrote:
> On Sat, Jan 31, 2009 at 11:37 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> I've been doing some benchmarking and profiling on the PostgreSQL
>> query analyzer, and it seems that (at least for the sorts of queries
>> that I typically run) the dominant cost is add_path(). I've been able
>> to find two optimizations that seem to help significantly:
>>
>> 1. add_path() often calls compare_fuzzy_path_costs() twice on the same
>>
>> 2. match_unsorted_outer() adds as many as 5 nested loop joins at a
>
> if there are two optimizations maybe two different patches are better
> to test them individually

I did test the changes independently and either one alone has a
measurable benefit (with sufficiently careful measuring), but they're
closely related changes so I think it makes more sense as one patch.
It's only 84 insertions and 46 deletions, so we're not talking about
some massive patch that will be difficult to review. There's also
some synergy between the two changes: I don't think either works as
well without the other. But please feel free to test it for yourself
and let me know what you find. The changes are all very simple - the
hard part was figuring out which changes would actually produce a
benefit.

...Robert

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua Tolley 2009-02-01 20:15:38 Re: adding stuff to parser, question
Previous Message Jaime Casanova 2009-02-01 18:34:51 Re: add_path optimization