Re: Re: Heaps of read() syscalls by the postmaster

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

In response to

Responses

Browse pgsql-hackers by date

  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