Re: add_path optimization
От | Robert Haas |
---|---|
Тема | Re: add_path optimization |
Дата | |
Msg-id | 603c8f070902011012n32a49ac0rf7abf7059795b2b1@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: add_path optimization (David Fetter <david@fetter.org>) |
Ответы |
Re: add_path optimization
|
Список | pgsql-hackers |
On Sun, Feb 1, 2009 at 12:03 PM, David Fetter <david@fetter.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
В списке pgsql-hackers по дате отправления: