From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Bryan Murphy <bmurphy1976(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Help Me Understand Why I'm Getting a Bad Query Plan |
Date: | 2009-03-25 02:30:10 |
Message-ID: | 49C99732.8080703@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Brian,
> I hate to nag, but could anybody help me with this? We have a few
> related queries that are causing noticeable service delays in our
> production system. I've tried a number of different things, but I'm
> running out of ideas and don't know what to do next.
For some reason, your first post didn't make it to the list, which is
why nobody responded.
>> I've got a query on our production system that isn't choosing a good
>> plan. I can't see why it's choosing to do a sequential scan on the
>> ItemExperienceLog table. That table is about 800mb and has about 2.5
>> million records. This example query only returns 4 records. I've
>> tried upping the statics for ItemExperienceLog.VistorId and
>> ItemExperienceLog.ItemId to 1000 (from out default of 100) with no
>> success.
Yes, that is kind of inexplicable. For some reason, it's assigning a
very high cost to the nestloops, which is why it wants to avoid them
with a seq scan. Can you try lowering cpu_index_cost to 0.001 and see
how that affects the plan?
--Josh
From | Date | Subject | |
---|---|---|---|
Next Message | marcin mank | 2009-03-25 03:04:08 | Re: Help Me Understand Why I'm Getting a Bad Query Plan |
Previous Message | Scott Marlowe | 2009-03-25 02:11:07 | Re: Raid 10 chunksize |