Re: Weird issue with planner choosing seq scan

On Feb 24, 2008, at 4:27 PM, Scott Marlowe wrote:

> On Sun, Feb 24, 2008 at 6:05 PM, Sean Leach <sleach@wiggum.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