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
|
Список | 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 по дате отправления: