Re: Problem with large table not using indexes (I think) - Mailing list pgsql-admin

From Benjamin Arai
Subject Re: Problem with large table not using indexes (I think)
Date
Msg-id 458D88E6.80609@araisoft.com
Whole thread Raw
In response to Re: Problem with large table not using indexes (I think)  (Jeff Frost <jeff@frostconsultingllc.com>)
List pgsql-admin
One more note about my problem,  when you run a query on older data in
the table then it work great but if you query newer data then is very slow.

Ex.

SELECT * from my_table WHERE date >=12/1/2005 and date <= 12/1/2006; <- slow

SELECT * from my_table WHERE date >=12/1/2002 and date <= 12/1/2003; <- fast

It just has to do with the new data for some reason.

Benjamin

Jeff Frost wrote:
> On Sat, 23 Dec 2006, Benjamin Arai wrote:
>
>> The largest table in my database (30GB) has mysteriously went from
>> taking milli-seconds to perform a query to minutes.  This disks are
>> fine and I have a 4GB shared_memory.  Could this slow down have to do
>> with the fsm_max_pages or something else like that?  I made it larger
>> but the queries still taking a long time.  I do daily vacuum's but I
>> don't run it with -z or --full.  I would like to avoid doing a --full
>> if possible because it would literally take over a week to complete.
>> Any help would be greatly appreciated.
>
> Benjamin,
>
> When is the last time you ran ANALYZE?  That's what the -z option
> does.  If you're only vacuuming once daily, you should definitely
> analyze with the -z flag as well.
>

pgsql-admin by date:

Previous
From: Benjamin Arai
Date:
Subject: Re: Problem with large table not using indexes (I think)
Next
From: Jeff Frost
Date:
Subject: Re: Problem with large table not using indexes (I think)