Re: Shouldn't we have a way to avoid "risky" plans? - Mailing list pgsql-performance

From Joshua Berkus
Subject Re: Shouldn't we have a way to avoid "risky" plans?
Date
Msg-id 634838041.271503.1301101397390.JavaMail.root@mail-1.01.com
Whole thread Raw
In response to Re: Shouldn't we have a way to avoid "risky" plans?  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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
thecosts. 

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
italone. 

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

pgsql-performance by date:

Previous
From: Nathan Boley
Date:
Subject: Re: Shouldn't we have a way to avoid "risky" plans?
Next
From: Greg Smith
Date:
Subject: Re: buffercache/bgwriter