From: Mladen Gogala <mladen.gogala@vmsinfo.com>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: anti-join chosen even when slower than old plan
Date: Thu, 11 Nov 2010 00:14:18 -0500
Message-ID: <4CDB7BAA.7020506@vmsinfo.com> (raw)
In-Reply-To: <4CDACBBF020000250003755B@gw.wicourts.gov>
References: <4CD9663502000025000374B1@gw.wicourts.gov>
<20961.1289347680@sss.pgh.pa.us>
<4CDA62C60200002500037512@gw.wicourts.gov>
<AANLkTi=eNXKEBo5dXJDd4+aHhfmkibH++fqjj12+DA3o@mail.gmail.com>
<4CDACBBF020000250003755B@gw.wicourts.gov>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: mladen.gogala@vmsinfo.com, Kevin.Grittner@wicourts.gov, robertmhaas@gmail.com, tgl@sss.pgh.pa.us
Subject: Re: anti-join chosen even when slower than old plan
In-Reply-To: <4CDB7BAA.7020506@vmsinfo.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox