Thread: BUG #1186: Broken Index?

The following bug has been logged online:

Bug reference:      1186
Logged by:          Gosen, Hitoshi

Email address:      mic-gosen@ns.inter-mic.co.jp

PostgreSQL version: 7.4

Operating system:   linux 2.4.18

Description:        Broken Index?

Details:

Hello All,
We are using PostgreSQL 7.4.2 for our website that handles over 200,000
transactions a day.
About a month ago, the responses from the SELECT queries on the database
became terribly slow.
We tried to anaylze the cause of the problem, searching throught the system
logs and all, but nothing appeared to be out of the ordinary.

What we did to resolve this was to dump the database, delete the database,
recreate the database, and finally restore it. After that, things were back
to normal.

From the above experience, we were able to hypothesize that the fault of the
slow responses was not from a broken data or hardware failures, but from a
broken index, since we were able to recover 100% of the data on the same
machine.

Today, the same problem occured, and the same actions are going to be taken
to temporary resolve it.

Final note: we will also experiment with the  'vacuum full' command to see
if it counters this problem.

On Fri, Jul 02, 2004 at 04:50:07 -0300,
  PostgreSQL Bugs List <pgsql-bugs@postgresql.org> wrote:
>
> The following bug has been logged online:

This doesn't appear to be a bug at this point. It sounds like you have
a self induced performance problem, so I am moving the discussion to
pgsql-performance.

>
> Bug reference:      1186
> Logged by:          Gosen, Hitoshi
>
> Email address:      mic-gosen@ns.inter-mic.co.jp
>
> PostgreSQL version: 7.4
>
> Operating system:   linux 2.4.18
>
> Description:        Broken Index?
>
> Details:
>
> Hello All,
> We are using PostgreSQL 7.4.2 for our website that handles over 200,000
> transactions a day.
> About a month ago, the responses from the SELECT queries on the database
> became terribly slow.
> We tried to anaylze the cause of the problem, searching throught the system
> logs and all, but nothing appeared to be out of the ordinary.
>
> What we did to resolve this was to dump the database, delete the database,
> recreate the database, and finally restore it. After that, things were back
> to normal.
>
> From the above experience, we were able to hypothesize that the fault of the
> slow responses was not from a broken data or hardware failures, but from a
> broken index, since we were able to recover 100% of the data on the same
> machine.
>
> Today, the same problem occured, and the same actions are going to be taken
> to temporary resolve it.
>
> Final note: we will also experiment with the  'vacuum full' command to see
> if it counters this problem.

It sounds like you aren't properly vacuuming your database. It is possible
that you need a higher FSM setting or to vacuum more frequently.

PostgreSQL Bugs List wrote:
> Hello All,
> We are using PostgreSQL 7.4.2 for our website that handles over 200,000
> transactions a day.
> About a month ago, the responses from the SELECT queries on the database
> became terribly slow.
> We tried to anaylze the cause of the problem, searching throught the system
> logs and all, but nothing appeared to be out of the ordinary.
>
> What we did to resolve this was to dump the database, delete the database,
> recreate the database, and finally restore it. After that, things were back
> to normal.
>
> From the above experience, we were able to hypothesize that the fault of the
> slow responses was not from a broken data or hardware failures, but from a
> broken index, since we were able to recover 100% of the data on the same
> machine.
>
> Today, the same problem occured, and the same actions are going to be taken
> to temporary resolve it.
>
> Final note: we will also experiment with the  'vacuum full' command to see
> if it counters this problem.

This is not for sure a bug, but a known behaviour if you don't vacuum at all
your db. I bet you don't use the vacuum daemon; use it or schedule a simple
vacuum on the eavily updated table each 10 minutes. I strongly suggest you to use
the autovacuum daemon.

Do not esitate to ask how use it.


Regards
Gaetano Mendola