Skip site navigation (1) Skip section navigation (2)

Re: add_path optimization

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: add_path optimization
Date: 2009-02-28 04:06:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I first tried just the compare_fuzzy_path_costs() change and really
>> couldn't measure any reliable difference. oprofile output for CVS HEAD
>> looks like

> Well, there's obviously something different between your case and
> mine, because in my query add_path was the #1 CPU hog and it wasn't
> close.  I suspect my query had more joins - I'll take a look at yours.

Interesting.  I'd like to see your example too, if you can publish it.
You had noted that add_path seemed to iterate clear to the end of the
list in most cases, which it's designed not to do, so there might be
something else going on in your example.

One other thought to roll around in your head: at the time that the
current add_path logic was designed, compare_pathkeys was ungodly
expensive, which is why the code tries to compare costs first.
We've since introduced the "canonical pathkey" representation, which
makes compare_pathkeys enough cheaper that it might not be insane
to do it in the other order.  I don't immediately see an easy win
there, because as things are structured we typically want the cost
comparison result anyway for list sorting purposes.  But maybe there's
a way around that.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Grzegorz JaskiewiczDate: 2009-02-28 10:44:32
Subject: would it be a lot of work, to add optimizations accross unions ?
Previous:From: Andrew DunstanDate: 2009-02-28 03:55:17
Subject: Re: xpath processing brain dead

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group