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

Re: Optimization idea

From: Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Vlad Arkhipov <arhipov(at)dc(dot)baikal(dot)ru>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Optimization idea
Date: 2010-04-23 13:09:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
2010/4/23 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Thu, Apr 22, 2010 at 10:37 PM, Vlad Arkhipov <arhipov(at)dc(dot)baikal(dot)ru> wrote:
>> I don't think this is just an issue with statistics, because the same
>> problem arises when I try executing a query like this:
> I'm not sure how you think this proves that it isn't a problem with
> statistics, but I think what you should be focusing on here, looking
> back to your original email, is that the plans that are actually much
> faster have almost as much estimated cost as the slower one.  Since
> all your data is probably fully cached, at a first cut, I might try
> setting random_page_cost and seq_page_cost to 0.005 or so, and
> adjusting effective_cache_size to something appropriate.

that will help worrect the situation, but the planner is loosing here I think.

> ...Robert
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:

Cédric Villemain

In response to


pgsql-performance by date

Next:From: Robert HaasDate: 2010-04-23 13:36:40
Subject: Re: Optimization idea
Previous:From: Robert HaasDate: 2010-04-23 11:05:53
Subject: Re: Optimization idea

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