Re: [HACKERS] More detail on settings for pgavd?

From: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
To: josh(at)agliodbs(dot)com
Cc: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, Shridhar Daithankar <shridhar_daithankar(at)myrealbox(dot)com>, pgsql-performance(at)postgresql(dot)org, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] More detail on settings for pgavd?
Date: 2003-11-21 22:40:45
Message-ID: 3FBE946D.4050708@zeut.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Josh Berkus wrote:

>Matthew,
>
>
>>I certainly agree that less than 10% would be excessive, I still feel
>>that 10% may not be high enough though. That's why I kinda liked the
>>sliding scale I mentioned earlier, because I agree that for very large
>>tables, something as low as 10% might be useful, but most tables in a
>>database would not be that large.
>>
>>
>
>Yes, but I thought that we were taking care of that through the "threshold"
>value?
>
>
Well the threshold is a combination of the base value and the scaling
factor which you are proposing is 0.1, so the threshold is base +
(scaling factor)(num of tuples) So with the default base of 1000 and
your 0.1 you would have this:

Num Rows threshold Percent
1,000 1,100 110%
10,000 2,000 20%
100,000 11,000 11%
1,000,000 102,000 10%

I don't like how that looks, hence the thought of some non-linear
scaling factor that would still allow the percent to reach 10%, but at a
slower rate, perhaps just a larger base value would suffice, but I think
small table performance is going to suffer much above 1000. Anyone else
have an opinion on the table above? Good / Bad / Indifferent?

>A sliding scale would also be OK. However, that would definitely require a
>leap to storing per-table pg_avd statistics and settings.
>
>
>
I don't think it would, it would correlate the scaling factor with the
number of tuples, no per-table settings required.

>>Only that pg_autovacuum isn't smart enough to kick off more than one
>>vacuum at a time. Basically, pg_autovacuum issues a vacuum on a table
>>and waits for it to finish, then check the next table in it's list to
>>see if it needs to be vacuumed, if so, it does it and waits for that
>>vacuum to finish.
>>
>>
>
>OK, then, we just need to detect the condition of the vacuums "piling up"
>because they are happening too often.
>
>
>
That would be good to look into at some point, especially if vacuum is
going to get slower as a result of the page loop delay patch that has
been floating around.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-11-21 22:48:03 Re: conversion dumping patch
Previous Message Peter Eisentraut 2003-11-21 22:09:07 ObjectWeb/Clustered JDBC

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2003-11-21 23:04:56 Re: [HACKERS] More detail on settings for pgavd?
Previous Message Matthew T. O'Connor 2003-11-21 21:52:29 Re: [HACKERS] More detail on settings for pgavd?