Re: Re: Heaps of read() syscalls by the postmaster
От | Tom Lane |
---|---|
Тема | Re: Re: Heaps of read() syscalls by the postmaster |
Дата | |
Msg-id | 7678.958745446@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: Heaps of read() syscalls by the postmaster ("Matthias Urlichs" <smurf@noris.net>) |
Ответы |
Re: Re: Heaps of read() syscalls by the postmaster
Re: Re: Heaps of read() syscalls by the postmaster |
Список | 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 по дате отправления: