Search Postgresql Archives

Re: Postgresql performance in production environment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Phoenix Kiula wrote:
> On 19/08/07, Magnus Hagander <magnus@xxxxxxxxxxxx> wrote:
>> Phoenix Kiula wrote:
>>> On 19/08/07, Magnus Hagander <magnus@xxxxxxxxxxxx> wrote:
> 
> 
>>> should we do one (VACUUM FULL) now given that we've overrun our max_fsm_pages?
>> Yes, but not until you've fixed it. And only once.
>>
> 
> 
> 
> FIxed what - the max_fsm_pages? That was my question: how to know what
> value to set for this. If the "vacuum verbose" won't give me the info
> you suggested because it is likely overlapping with autovacuum, should
> I temporarily turn autovacuum off and then run vacuum verbose? Also,
> while running vacuum full, any precautions to take?

Yeah, you can do that - or you can just trawl back through the logs to
find that information - it's there somewhere. grep would be helpful to
find it.

vacuum full will take out blocking locks on your database, so run it
during a maintenance window or at least during a low-traffic time.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux