Re: Re: Heaps of read() syscalls by the postmaster - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: Heaps of read() syscalls by the postmaster
Date
Msg-id 7678.958745446@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: Heaps of read() syscalls by the postmaster  ("Matthias Urlichs" <smurf@noris.net>)
Responses Re: Re: Heaps of read() syscalls by the postmaster  ("Matthias Urlichs" <smurf@noris.net>)
Re: Re: Heaps of read() syscalls by the postmaster  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
"Matthias Urlichs" <smurf@noris.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


pgsql-hackers by date:

Previous
From: "Matthias Urlichs"
Date:
Subject: Re: Performance (was: The New Slashdot Setup (includes MySql server))
Next
From: "Matthias Urlichs"
Date:
Subject: Re: Re: Heaps of read() syscalls by the postmaster