Re: anti-join chosen even when slower than old plan - Mailing list pgsql-performance

From Mladen Gogala
Subject Re: anti-join chosen even when slower than old plan
Date
Msg-id 4CDB7BAA.7020506@vmsinfo.com
Whole thread Raw
In response to Re: anti-join chosen even when slower than old plan  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: anti-join chosen even when slower than old plan  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-performance
On 11/10/2010 5:43 PM, Kevin Grittner wrote:
The only half-sane answer I've thought of is to apply a different
cost to full-table or full-index scans based on the ratio with
effective cache size. 

The "effective_cache_size" is, in my humble opinion, a wrong method.  It would be much easier to have a parameter, let's call it "optimizer_index_caching", which would give the assumption of the percentage of an index that is cached. In other words, if "optimizer_index_caching" was set to 80, the optimizer would assume that 80% of any index is cached and would apply different cost estimate. It's not exact but it's simple and modifiable. It would also be a great tool in the hands of the DBA which has to manage OLTP database or DW database and would be able to create a definitive bias toward one type of the execution plan.
I have to confess that the idea about such parameter is not entirely mine: http://tinyurl.com/33gu4f6

-- 
Mladen Gogala 
Sr. Oracle DBA
1500 Broadway
New York, NY 10036
(212) 329-5251
www.vmsinfo.com 

pgsql-performance by date:

Previous
From: Robert Haas
Date:
Subject: Re: anti-join chosen even when slower than old plan
Next
From: Віталій Тимчишин
Date:
Subject: Re: anti-join chosen even when slower than old plan