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

Re: Weird issue with planner choosing seq scan

From: Sean Leach <sleach(at)wiggum(dot)com>
To: pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Weird issue with planner choosing seq scan
Date: 2008-02-25 14:13:49
Message-ID: D6BCD267-9BBA-4A2C-A86B-632E2DD76A31@wiggum.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Feb 24, 2008, at 4:27 PM, Scott Marlowe wrote:

> On Sun, Feb 24, 2008 at 6:05 PM, Sean Leach <sleach(at)wiggum(dot)com> wrote:
>
>> On Feb 24, 2008, at 4:03 PM, Scott Marlowe wrote:
>>
>>>
>>> What version pgsql is this?  If it's pre 8.0 it might be worth  
>>> looking
>>> into migrating for performance and maintenance reasons.
>>
>> It's the latest 8.3.0 release :(
>
> Urg.  Then I wonder how your indexes are bloating but your table is
> not...  you got autovac running?  No weird lock issues?  It's a side
> issue right now since the table is showing as non-bloated (unless
> you've got a long running transaction and that number is WAY off from
> your vacuum)


Autovac is running, but probably not tuned.  I am looking at my  
max_fsm_pages setting to up as vacuum says, but not sure which value  
to use (all the posts on the web refer to what looks like an old  
vacuum output format), is this the line to look at?

INFO:  "u_counts": found 0 removable, 6214708 nonremovable row  
versions in 382344 pages
DETAIL:  2085075 dead row versions cannot be removed yet.

I.e. I need 382344 max_fsm_pages?  No weird lock issues that we have  
seen.

So should I do a vacuum full and then hope this doesn't happen again?   
Or should I run a VACUUM FULL after each aggregation run?

Thanks!
Sean


In response to

Responses

pgsql-performance by date

Next:From: MatthewDate: 2008-02-25 14:27:12
Subject: Re: Weird issue with planner choosing seq scan
Previous:From: Nikolas EverettDate: 2008-02-25 14:11:29
Subject: Re: response time when querying via JDBC and via psql differs

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