Обсуждение:

"John Lister" <john.lister-ps@kickstone.com> wrote:

> I'm using 8.3.8

That's recent.  :-)  If you have index bloat you either have some
process has held open a database transaction for a very long time
while the table underwent updates or deletes, or your vacuum policy
is not aggressive enough.

> my indexes seem to grow disproportionately to the size of the
> tables, but I haven't studied it in detail yet - I was trying to
> increase performance on a number of tables that seem to be
> extremely bloated for some reason.

Well, if they're already extremely bloated, you may need to use
CLUSTER or some other technique to recover; but it is important to
understand how you got into that state so you can avoid doing it
again.

By the way, how are you measuring bloat, and how extreme is it?

-Kevin

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote:
> "John Lister" <john.lister-ps@kickstone.com> wrote:
>> I'm using 8.3.8
>
> That's recent.  :-)

Thanks for the reply, wasn't sure if 8.4 had fixed anything :)

> If you have index bloat you either have some
> process has held open a database transaction for a very long time
> while the table underwent updates or deletes, or your vacuum policy
> is not aggressive enough.
>
>> my indexes seem to grow disproportionately to the size of the
>> tables, but I haven't studied it in detail yet - I was trying to
>> increase performance on a number of tables that seem to be
>> extremely bloated for some reason.
>
> Well, if they're already extremely bloated, you may need to use
> CLUSTER or some other technique to recover; but it is important to
> understand how you got into that state so you can avoid doing it
> again.
>
> By the way, how are you measuring bloat, and how extreme is it?

at the extreme case one table was 30Gb with 25Gb of indexes and after
forcing a full vacuum and reindex dropped to around  7gb each.
the stats claimed that autovacuum had run fairly recently (in fact it was
trying to run as I glomped it) and I can't see any long standing
transactions, but the db
had been up for over a year so it is possible some hung around longer than
they should.
As you say, I suspect I may have had the autovacuum settings too low so as
to avoid loading the db too much (it seems to be a delicate balance between
having autovacuum run and slowing down normal use) and have upped them a
little. but wanted to make sure that (auto)vacuum was doing what I thought
before getting more aggressive with them

Thanks

John

"John Lister" <john.lister-ps@kickstone.com> wrote:

> As you say, I suspect I may have had the autovacuum settings too
> low so as to avoid loading the db too much (it seems to be a
> delicate balance between having autovacuum run and slowing down
> normal use) and have upped them a little. but wanted to make sure
> that (auto)vacuum was doing what I thought before getting more
> aggressive with them

When we first started using PostgreSQL we initially had problems
with bloat and the autovacuum process started creating significant
load.  Our first reaction was to make autovacuum less aggressive,
but this just made things worse.  The counter-intuitive step of
making autovacuum very aggressive actually prevented bloat to the
point where autovacuum wound up creating less load.  Don't be shy
about running it frequently and at low thresholds; but if it does
have a performance impact, a small autovacuum_cost_delay (I've never
needed more than 10ms) will probably solve the issue.

-Kevin

 "Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote:
> When we first started using PostgreSQL we initially had problems
> with bloat and the autovacuum process started creating significant
> load.  Our first reaction was to make autovacuum less aggressive,
> but this just made things worse.  The counter-intuitive step of
> making autovacuum very aggressive actually prevented bloat to the
> point where autovacuum wound up creating less load.  Don't be shy
> about running it frequently and at low thresholds; but if it does
> have a performance impact, a small autovacuum_cost_delay (I've never
> needed more than 10ms) will probably solve the issue.

Cheers, I might give that a go. I've set the cost_delay to 10 already, so
will decrease the thresholds more and see what happens.

John

my happiness!
I found a large-scale sales compan-- Kimsell.There are favourable price and fine quality goods very much.When I ordered
theDell computer,in one week,I received it and found it very well in the quality.I am very happy for the purching.I
hopethat you can share my happiness. www.ynchenxi.com 
You can find what you want to.
Greetings!
_________________________________________________________________
Browse profiles for FREE! Meet local singles online.
http://clk.atdmt.com/NMN/go/150855801/direct/01/