Re: vacuum full & max_fsm_pages question

From: Patrick Hatcher <PHatcher(at)macys(dot)com>
To: "Josh Berkus <josh" <josh(at)agliodbs(dot)com>
Cc: "Patrick Hatcher" <pathat(at)comcast(dot)net>, pgsql-performance(at)postgresql(dot)org, pgsql-performance-owner(at)postgresql(dot)org, "Robert Treat" <xzilla(at)users(dot)sourceforge(dot)net>
Subject: Re: vacuum full & max_fsm_pages question
Date: 2004-09-23 16:32:50
Message-ID: OF207DA128.AD1DC706-ON88256F18.005AB6F6-88256F18.005C0EBF@fds.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

I upgraded to 7.4.3 this morning and did a vacuum full analyze on the
problem table and now the indexes show the correct number of records

Patrick Hatcher
Macys.Com

Josh Berkus <josh(at)agliodbs(dot)com>
Sent by: pgsql-performance-owner(at)postgresql(dot)org
09/21/04 10:49 AM

To
"Patrick Hatcher" <pathat(at)comcast(dot)net>
cc
"Robert Treat" <xzilla(at)users(dot)sourceforge(dot)net>,
<pgsql-performance(at)postgresql(dot)org>
Subject
Re: [PERFORM] vacuum full & max_fsm_pages question

Patrick,

> Sorry. I wrote PG 7.4.2 and then I erased it to write something else
and
> then forgot to add it back.

Odd. You shouldn't be having to re-vacuum on 7.4.

> And thanks for the Page info. I was getting frustrated and looked in
the
> wrong place.
>
> So it's probably best to drop and readd the indexes then?

Well, I have to wonder if you've not run afoul of the known 7.4.2 bug
regarding indexes. This system hasn't had an improper database shutdown
or
power-out in the last few weeks, has it?

--
Josh Berkus
Aglio Database Solutions
San Francisco

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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jason Coene 2004-09-23 16:53:25 Re: Caching of Queries
Previous Message Mr Pink 2004-09-23 15:39:31 Re: SAN performance