Re: Performance features the 4th

Jan Wieck <janwieck@yahoo.com>

From: Jan Wieck <JanWieck@Yahoo.com>
To: "Matthew T. O'Connor" <matthew@zeut.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Christopher Browne <cbbrowne@acm.org>, pgsql-hackers@postgresql.org
Date: 2003-11-09T23:42:53Z
Lists: pgsql-hackers

Attachments

Matthew T. O'Connor wrote:

> ----- Original Message ----- 
> From: "Jan Wieck" <JanWieck@Yahoo.com>
>> Tom Lane wrote:
>> > Gaetano and a couple of other people did experiments that seemed to show
>> > it was useful.  I think we'd want to change the shape of the knob per
>> > later suggestions (sleep 10 ms every N blocks, instead of N ms every
>> > block) but it did seem that there was useful bang for little buck there.
>>
>> I thought it was "sleep N ms every M blocks".
>>
>> Have we seen any numbers? Anything at all? Something that gives us a
>> clue by what factor one has to multiply the total time a "VACUUM
>> ANALYZE" takes, to get what effect in return?
> 
> I have some time on sunday to do some testing.  Is there a patch that I can
> apply that implements either of the two options? (sleep 10ms every M blocks
> or sleep N ms every M blocks).
> 
> I know Tom posted the original patch that sleept N ms every 1 block (where N
> is > 10 due to OS limitations).  Jan can you post a patch that has just the
> sleep code in it? Or should it be easy enough for me to cull out of the
> larger patch you posted?

Sorry for the delay, had to finish some other concept yesterday (will be 
published soon).

The attached patch adds

     vacuum_group_delay_size = 10 (range 1-1000)
     vacuum_group_delay_msec = 0  (range 0-1000)

and does the sleeping via select(2). It does it only at the same places 
where Tom had done the usleep() in his hack, so I guess there is still 
some more to do besides the documentation, before it can be added to 
7.4.1. But it should be enough to get some testing done.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #