Re: Weird issue with planner choosing seq scan

Поиск
Список
Период
Сортировка
От Sean Leach
Тема Re: Weird issue with planner choosing seq scan
Дата
Msg-id D6BCD267-9BBA-4A2C-A86B-632E2DD76A31@wiggum.com
обсуждение исходный текст
Ответ на Re: Weird issue with planner choosing seq scan  ("Scott Marlowe" <scott.marlowe@gmail.com>)
Ответы Re: Weird issue with planner choosing seq scan  ("Stephen Denne" <Stephen.Denne@datamail.co.nz>)
Список 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 по дате отправления:

Предыдущее
От: "Nikolas Everett"
Дата:
Сообщение: Re: response time when querying via JDBC and via psql differs
Следующее
От: Matthew
Дата:
Сообщение: Re: Weird issue with planner choosing seq scan