Re: Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3

From: Shaun Thomas <sthomas(at)peak6(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "tgarnett(at)panjiva(dot)com" <tgarnett(at)panjiva(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3
Date: 2011-03-16 18:34:52
Message-ID: 4D8102CC.5060309@peak6.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 03/16/2011 12:44 PM, Kevin Grittner wrote:

> Well, that's one way of looking at it. Another would be that the
> slower plan with the backward scan was only estimated to be 14.5%
> less expensive than the fast plan, so a pretty moderate modifier
> would have avoided this particular problem.

I was wondering about that myself. Considering any backwards scan would
necessarily be 10-100x slower than a forward scan unless the data was on
an SSD, I assumed the planner was already using a multiplier to
discourage its use.

If not, it seems like a valid configurable. We set our random_page_cost
to 1.5 once the DB was backed by NVRAM. I could see that somehow
influencing precedence of a backwards index scan. But even then, SSDs
and their ilk react more like RAM than even a large RAID... so should
there be a setting that passes such useful info to the planner?

Maybe a good attribute to associate with the tablespace, if nothing else.

--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604
312-676-8870
sthomas(at)peak6(dot)com

______________________________________________

See http://www.peak6.com/email_disclaimer.php
for terms and conditions related to this email

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Claudio Freire 2011-03-16 18:39:26 Re: Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3
Previous Message Kevin Grittner 2011-03-16 17:44:31 Re: Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3