Re: Performance problems with large telemetric datasets on 7.4.2 - Mailing list pgsql-performance

From Sven Clement
Subject Re: Performance problems with large telemetric datasets on 7.4.2
Date
Msg-id 881035ea0708060254w32fa164di32d3579c2b0ebf14@mail.gmail.com
Whole thread Raw
In response to Re: Performance problems with large telemetric datasets on 7.4.2  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: Performance problems with large telemetric datasets on 7.4.2  ("Scott Marlowe" <scott.marlowe@gmail.com>)
List pgsql-performance
Ok thanks everybody for the calrification, after all now I allready learned something new... ;)

My employer is currently thinking about migration to 8.2.x because of your feedback, so I think that the problem could be resolved... ;)

Thanks to everyone...

Sven Clement

2007/8/6, Heikki Linnakangas <heikki@enterprisedb.com>:
Sven Clement wrote:
> Partially I found that one in the PostgreSQL Documentation for the
> 7.x.xversions under the command REINDEX where they claim that you
> should run a
> reindex under certain circumstances and for my comprehension this says that
> with some access pattern (as ours (major writes / one big delete per day))
> the index may be corrupted or otherwise not really useful.

Up to 7.3, periodical REINDEX was needed to trim down bloated indexes.
Since 7.4, empty index pages are recycled so that's no longer necessary.
You can still end up with larger than necessary indexes in recent
versions under unusual access patterns, like if you delete all but a few
index tuples from each index page, but it's rare in practice. And it's
not unbounded growth like in <= 7.3.

In any case, the indexes won't become corrupt.

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com



--
DSIGN.LU
Sven Clement
+352 621 63 21 18
sven@dsign.lu

www.dsign.lu

pgsql-performance by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Performance problems with large telemetric datasets on 7.4.2
Next
From: Henrik Zagerholm
Date:
Subject: Planner making wrong decisions 8.2.4. Insane cost calculations.