Thread: Build sizes vs docs

Build sizes vs docs

From
Magnus Hagander
Date:
Came cross this when updating the cvs fix. We declare size requirements as:
  Also check that you have sufficient disk space. You will need about  65 MB for the source tree during compilation and
about MB for  the installation directory. An empty database cluster takes about  25 MB; databases take about five times
theamount of space that a  flat text file with the same data would take. If you are going to  run the regression tests
youwill temporarily need up to an extra  90 MB. Use the <command>df</command> command to check free disk
 


My source *without* compile is 82 Mb, and with a build in it (linux
i686) is 110Mb during compilations, rather than 65.
An empty cluster takes about 33Mb.
The regression database takes about 132Mb.
(this is 8.4)


Should we fix these numbers, or just remove them? They're clearly
platform dependent, but perhaps there's still a point in including
them - mainly as hints?


-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/


Re: Build sizes vs docs

From
Tom Lane
Date:
Magnus Hagander <magnus@hagander.net> writes:
> Came cross this when updating the cvs fix. We declare size requirements as:
>    Also check that you have sufficient disk space. You will need about
>    65 MB for the source tree during compilation and about  MB for
>    the installation directory. An empty database cluster takes about
>    25 MB; databases take about five times the amount of space that a
>    flat text file with the same data would take. If you are going to
>    run the regression tests you will temporarily need up to an extra
>    90 MB. Use the <command>df</command> command to check free disk

> My source *without* compile is 82 Mb, and with a build in it (linux
> i686) is 110Mb during compilations, rather than 65.
> An empty cluster takes about 33Mb.
> The regression database takes about 132Mb.
> (this is 8.4)

> Should we fix these numbers, or just remove them? They're clearly
> platform dependent, but perhaps there's still a point in including
> them - mainly as hints?

Maybe round them off to an order of magnitude.  I think it's useful
to have some idea of the size requirements, even if they change over
time.  It wouldn't be a bad idea to say "as of 8.4" or some such, too.
        regards, tom lane


Re: Build sizes vs docs

From
Magnus Hagander
Date:
2009/12/7 Tom Lane <tgl@sss.pgh.pa.us>:
> Magnus Hagander <magnus@hagander.net> writes:
>> Came cross this when updating the cvs fix. We declare size requirements as:
>>    Also check that you have sufficient disk space. You will need about
>>    65 MB for the source tree during compilation and about  MB for
>>    the installation directory. An empty database cluster takes about
>>    25 MB; databases take about five times the amount of space that a
>>    flat text file with the same data would take. If you are going to
>>    run the regression tests you will temporarily need up to an extra
>>    90 MB. Use the <command>df</command> command to check free disk
>
>> My source *without* compile is 82 Mb, and with a build in it (linux
>> i686) is 110Mb during compilations, rather than 65.
>> An empty cluster takes about 33Mb.
>> The regression database takes about 132Mb.
>> (this is 8.4)
>
>> Should we fix these numbers, or just remove them? They're clearly
>> platform dependent, but perhaps there's still a point in including
>> them - mainly as hints?
>
> Maybe round them off to an order of magnitude.  I think it's useful
> to have some idea of the size requirements, even if they change over
> time.  It wouldn't be a bad idea to say "as of 8.4" or some such, too.

Hmm, I don't like that, it'll just make things look old :-) For now
I've applied a patch to update the values with what it is now.

Perhaps we should just add it to the release checklist to verify that
they are reasonably correct? Shouldn't take too long, and it's not
likely it'll ever change in a minor release - only major releases are
interesting.


-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/


Re: Build sizes vs docs

From
Tom Lane
Date:
Magnus Hagander <magnus@hagander.net> writes:
> Perhaps we should just add it to the release checklist to verify that
> they are reasonably correct?

Go for it.  Now that you mention it, there are some memory-usage tables
in the documentation about shared memory configuration that also have
a pretty short half-life, and should be rechecked.
        regards, tom lane


Re: Build sizes vs docs

From
Magnus Hagander
Date:
2009/12/9 Tom Lane <tgl@sss.pgh.pa.us>:
> Magnus Hagander <magnus@hagander.net> writes:
>> Perhaps we should just add it to the release checklist to verify that
>> they are reasonably correct?
>
> Go for it.  Now that you mention it, there are some memory-usage tables
> in the documentation about shared memory configuration that also have
> a pretty short half-life, and should be rechecked.

Done.

They're up-to-date per 8.3, btw. Are there changes in 8.4 that should
be put in? If so, it would be good to include it before the next minor
release, so the proper data goes up on the website.


-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/


Re: Build sizes vs docs

From
Alvaro Herrera
Date:
Magnus Hagander wrote:
> 2009/12/9 Tom Lane <tgl@sss.pgh.pa.us>:
> > Magnus Hagander <magnus@hagander.net> writes:
> >> Perhaps we should just add it to the release checklist to verify that
> >> they are reasonably correct?
> >
> > Go for it.  Now that you mention it, there are some memory-usage tables
> > in the documentation about shared memory configuration that also have
> > a pretty short half-life, and should be rechecked.
> 
> Done.
> 
> They're up-to-date per 8.3, btw. Are there changes in 8.4 that should
> be put in? If so, it would be good to include it before the next minor
> release, so the proper data goes up on the website.

At the very least we don't have the FSM bits anymore ...

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.