AW: pg_attribute growing and growing and growing

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas SB
Тема AW: pg_attribute growing and growing and growing
Дата
Msg-id 11C1E6749A55D411A9670001FA687963368058@sdexcsrv1.f000.d0188.sd.spardat.at
обсуждение исходный текст
Ответы Re: AW: pg_attribute growing and growing and growing  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> foo=# \d pg_attribute_relid_attnam_index
> Index "pg_attribute_relid_attnam_index"
>  Attribute | Type
> -----------+------
>  attrelid  | oid
>  attname   | name
> unique btree
> 
> foo=# \d pg_attribute_relid_attnum_index
> Index "pg_attribute_relid_attnum_index"
>  Attribute |   Type
> -----------+----------
>  attrelid  | oid
>  attnum    | smallint
> unique btree
> 
> Since table OIDs keep increasing, this formulation ensures that new
> entries will always sort to the end of the index, and so space freed
> internally in the indexes can never get re-used.  Swapping the column
> order may eliminate that problem --- but I'm not sure what if any
> speed penalty would be incurred.  Thoughts anyone?

Isn't pg_attribute often accessed with a "where oid=xxx" restriction
to get all cols for a given table ?

Andreas


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Horák Daniel
Дата:
Сообщение: RE: autoconf check for AF_UNIX sockets
Следующее
От: Tiago Antão
Дата:
Сообщение: Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan