Re: add_path optimization

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: add_path optimization
Date: 2009-03-02 23:09:00
Message-ID: 49AC12AC.EE98.0025.0@wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> After a lot of distractions, I've finished applying the planner
fixes
> that seem necessary in view of your report about poorer planning in
8.4
> than 8.3. When you have a chance, it would be useful to do a
thorough
> test of CVS HEAD on your data and query mix --- are there any other
> places where we have regressed relative to 8.3?

You probably already know this, but on the query referenced earlier in
the thread, a great plan is now generated! Even when not cached, this
executed in just under seven seconds. (I chose these values for
testing this query because it had been logged as exceeding 20 seconds
under 8.3.) Cached, EXPLAIN ANALYZE runs between 225 and 250 ms.
Running it without EXPLAIN the psql \timing is between 265 and 277 ms.
EXPLAIN gives a \timing averaging 80 ms.

I will see what kind of testing I can put together to try to shake out
any remaining issues.

-Kevin

Attachment Content-Type Size
plan.txt text/plain 15.1 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bryce Cutt 2009-03-02 23:47:34 Re: Proposed Patch to Improve Performance of Multi-BatchHash Join for Skewed Data Sets
Previous Message Merlin Moncure 2009-03-02 22:02:33 Re: statistics horribly broken for row-wise comparison