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
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 |