Re: Weird issue with planner choosing seq scan - Mailing list pgsql-performance

From Sean Leach
Subject Re: Weird issue with planner choosing seq scan
Date
Msg-id D6BCD267-9BBA-4A2C-A86B-632E2DD76A31@wiggum.com
Whole thread Raw
In response to Re: Weird issue with planner choosing seq scan  ("Scott Marlowe" <scott.marlowe@gmail.com>)
Responses Re: Weird issue with planner choosing seq scan
List 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@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


pgsql-performance by date:

Previous
From: "Nikolas Everett"
Date:
Subject: Re: response time when querying via JDBC and via psql differs
Next
From: Matthew
Date:
Subject: Re: Weird issue with planner choosing seq scan