From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Matthias Urlichs" <smurf(at)noris(dot)net> |
Cc: | Hannu Krosing <hannu(at)tm(dot)ee>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Re: Heaps of read() syscalls by the postmaster |
Date: | 2000-05-19 14:10:46 |
Message-ID: | 7678.958745446@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Matthias Urlichs" <smurf(at)noris(dot)net> writes:
>> Do we shrink system tables on vacuum ?
>>
> If the user calling the VACUUM has access rights to them, yes.
But the indexes don't shrink (same problem as for user indexes).
VACUUM doesn't really make any distinction between system tables and
user tables; they're all handled the same way. IIRC, the only
special-case in 7.0 is that it doesn't try to compute pg_statistic
entries for pg_statistic ;-)
>> It's possible that running some benchmark that creates/drops tables
>> repetedly will blow up the size of system tables incl. pg_attribute.
Yes, if you don't vacuum them every so often...
But what I don't understand is why a simple INSERT is doing a sequential
scan of pg_attribute. Presumably the parser needs to find out what the
table's columns are ... but why isn't the catcache providing the data?
Needs to be looked at.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 2000-05-19 14:16:34 | Re: OO Patch |
Previous Message | Hannu Krosing | 2000-05-19 14:05:16 | Re: Re: [SQL] Foreign keys breaks tables permissions |