From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: add_path optimization |
Date: | 2009-02-01 18:12:19 |
Message-ID: | 603c8f070902011012n32a49ac0rf7abf7059795b2b1@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Feb 1, 2009 at 12:03 PM, David Fetter <david(at)fetter(dot)org> wrote:
> On Sat, Jan 31, 2009 at 11:37:39PM -0500, Robert Haas 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:
>
> Are there any cases you've found where this change significantly
> impairs performance, and if so, how did you find them? If not, would
> you be up for trying to find some?
Basically, the patch is just performing the same operations with less
overhead. For example, add_similar_path() is pretty much the same
thing as repeated calls to add_path(), but you save the cost of
unnecessary pathkey comparisons and maybe some ListCell alloc/free
cycles. So I'm not really sure how it could make things worse, but
I'd be interested in knowing if there's a case that you're worried
about. It's pretty low-level code, so I don't think there's room for
a lot of surprises.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2009-02-01 18:34:51 | Re: add_path optimization |
Previous Message | David Fetter | 2009-02-01 17:03:43 | Re: add_path optimization |