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

Re: Shouldn't we have a way to avoid "risky" plans?

From: Joshua Berkus <josh(at)agliodbs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Claudio Freire <klaussfreire(at)gmail(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Shouldn't we have a way to avoid "risky" plans?
Date: 2011-03-26 01:03:17
Message-ID: 634838041.271503.1301101397390.JavaMail.root@mail-1.01.com (view raw or flat)
Thread:
Lists: pgsql-performance
> mergejoinscansel doesn't currently try to fix up the histogram bounds
> by
> consulting indexes. At the time I was afraid of the costs of doing
> that, and I still am; but it would be a way to address this issue.

Oh?  Hmmm.  I have a ready-made test case for the benefit case on this.   However, I'm not clear on how we would test the costs.

But this type of query plan is clearly pathological, and is experienced by users as a performance regression since 8.3.  I now have the user doing analyzes of fairly large tables 2/hour to avoid the problem.  So I don't think we can leave it alone.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
San Francisco

In response to

pgsql-performance by date

Next:From: Greg SmithDate: 2011-03-28 06:02:42
Subject: Re: buffercache/bgwriter
Previous:From: Nathan BoleyDate: 2011-03-25 22:43:04
Subject: Re: Shouldn't we have a way to avoid "risky" plans?

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