Build sizes vs docs

Started by Magnus Haganderabout 16 years ago6 messages
#1Magnus Hagander
magnus@hagander.net

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?

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

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Magnus Hagander (#1)
Re: Build sizes vs docs

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

#3Magnus Hagander
magnus@hagander.net
In reply to: Tom Lane (#2)
Re: Build sizes vs docs

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 Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Magnus Hagander (#3)
Re: Build sizes vs docs

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

#5Magnus Hagander
magnus@hagander.net
In reply to: Tom Lane (#4)
Re: Build sizes vs docs

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 Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

#6Alvaro Herrera
alvherre@commandprompt.com
In reply to: Magnus Hagander (#5)
Re: Build sizes vs docs

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.