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  ("Matthias Urlichs" <smurf@noris.net>)
Re: Re: Heaps of read() syscalls by the postmaster  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Matthias Urlichs"
Дата:
Сообщение: Re: Performance (was: The New Slashdot Setup (includes MySql server))
Следующее
От: "Matthias Urlichs"
Дата:
Сообщение: Re: Re: Heaps of read() syscalls by the postmaster