| From: | Joe Conway <mail(at)joeconway(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Al Bean <albean84(at)hotmail(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: the "/usr/local/pgsql/data" directory size |
| Date: | 2002-12-06 18:28:07 |
| Message-ID: | 3DF0EC37.6000606@joeconway.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Tom Lane wrote:
>>Other things I can think of:
>>1. Reduce NAMEDATALEN
>>2. Reduce INDEX_MAX_KEYS
>
> Neither of those are likely to change the disk footprint a lot, since
> the system catalogs aren't a significant proportion of any real-world
> database, I should think.
I was thinking of the benchmarking results we did for 7.3.
This one:
http://archives.postgresql.org/pgsql-hackers/2002-08/msg00258.php
showed about 12 to 15% increase in individual database size when changing from
INDEX_MAX_KEYS = 16 to INDEX_MAX_KEYS = 32.
And this one:
http://archives.postgresql.org/pgsql-hackers/2002-08/msg00333.php
showed about 11% increase increase in individual database size when changing
from NAMEDATALEN = 32 to NAMEDATALEN = 64.
For an embedded application, these kinds of savings might be important.
Joe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Taylor | 2002-12-06 18:39:01 | JDBC |
| Previous Message | Matthew Gabeler-Lee | 2002-12-06 18:14:40 | Another planner bug with subqueries |