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

From Bruce Momjian
Subject Re: Re: Heaps of read() syscalls by the postmaster
Date
Msg-id 200005191520.LAA05055@candle.pha.pa.us
Whole thread Raw
In response to Re: Re: Heaps of read() syscalls by the postmaster  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
If we create a unique index on a column, seems we could update
pg_statistic automatically to mark it as unique.


> "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
> 


--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Performance (was: The New Slashdot Setup (includes MySql server))
Next
From: Bruce Momjian
Date:
Subject: Re: Performance (was: The New Slashdot Setup (includes MySql server))