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

Re: anti-join chosen even when slower than old plan

From: Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: anti-join chosen even when slower than old plan
Date: 2010-11-11 05:14:18
Message-ID: 4CDB7BAA.7020506@vmsinfo.com (view raw or flat)
Thread:
Lists: 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

In response to

Responses

pgsql-performance by date

Next:From: 静安寺Date: 2010-11-11 07:03:45
Subject: Re: Why dose the planner select one bad scan plan.
Previous:From: Robert HaasDate: 2010-11-11 03:47:21
Subject: Re: anti-join chosen even when slower than old plan

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