Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system
Date
Msg-id CAFj8pRD4sr-nX7AFWCN2paquRPU1xSDW=PwXirrBUZSF3VUHUg@mail.gmail.com
Whole thread Raw
In response to Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
2013/2/6 Alvaro Herrera <alvherre@2ndquadrant.com>:
> Tom Lane escribió:
>> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> >> Nice. Another interesting numbers would be device utilization, average
>> >> I/O speed and required space (which should be ~2x the pgstat.stat size
>> >> without the patch).
>>
>> > this point is important - with large warehouse with lot of databases
>> > and tables you have move stat file to some ramdisc - without it you
>> > lost lot of IO capacity - and it is very important if you need only
>> > half sized ramdisc
>>
>> [ blink... ]  I confess I'd not been paying close attention to this
>> thread, but if that's true I'd say the patch is DOA.  Why should we
>> accept 2x bloat in the already-far-too-large stats file?  I thought
>> the idea was just to split up the existing data into multiple files.
>
> I think they are saying just the opposite: maximum disk space
> utilization is now half of the unpatched code.  This is because when we
> need to write the temporary file to rename on top of the other one, the
> temporary file is not of the size of the complete pgstat data collation,
> but just that for the requested database.

+1

Pavel

>
> --
> Álvaro Herrera                http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system
Next
From: Tom Lane
Date:
Subject: Re: sql_drop Event Trigger