pg_index updates and SI invalidation
От | Pavan Deolasee |
---|---|
Тема | pg_index updates and SI invalidation |
Дата | |
Msg-id | 2e78013d0703261027q6820df50i43a6d97ad6ff47a@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: pg_index updates and SI invalidation
|
Список | pgsql-hackers |
<br clear="all" /><br />While experimenting with the proposed CREATE INDEX support with<br />HOT, I realized that SI invalidationare not sent properly for pg_index<br />updates.<br /><br />I noticed the following comment in relcache.c <br/><br />/*<br /> * RelationReloadClassinfo - reload the pg_class row (only)<br /> *<br /> * This function is used onlyfor indexes. We currently allow only the<br /> * pg_class row of an existing index to change (to support changes of<br /> * owner, tablespace, or relfilenode), not its pg_index row or other<br /> * subsidiary index schema information. Therefore it's sufficient to do<br /> * this when we get an SI invalidation. Furthermore, there are cases<br /> * where it's necessary not to throw away the index information, especially<br /> * for "nailed" indexes whichwe are unable to rebuild on-the-fly.<br /> *<br /> * We can't necessarily reread the pg_class row right away; we mightbe <br /> * in a failed transaction when we receive the SI notification. If so,<br /> * RelationClearRelation justmarks the entry as invalid by setting<br /> * rd_isvalid to false. This routine is called to fix the entry when it<br /> * is next needed.<br /> */<br /><br />From the comment, its clear that we don't expect SI invalidation<br />towork correctly for pg_index row updates. We are thinking of<br />adding a new attribute to pg_index row to control theusability of <br />the index in queries. Is it worth spending time to support SI<br />invalidation for pg_index updatesor should we rather add the<br />attribute to pg_class though pg_index seems to the right place ?<br /><br />A side-effectof this limitation is that REINDEX does not make <br />an index immediately available in the same transactionif REINDEX<br />is used to fix an earlier failed CREATE INDEX CONCURRENTLY.<br />Though we set "indisvalid" to'true' at the end of REINDEX, the<br /> effect is not seen until the transaction completes because of<br />lack of SI invalidation.<br /><br />Any suggestions how should I proceed with this ? Should I add<br />a pg_class attribute or is itworth fixing pg_index SI invalidation ? <br /><br />Thanks,<br />Pavan<br /><br />-- <br /><br />EnterpriseDB <a href="http://www.enterprisedb.com">http://www.enterprisedb.com</a>
В списке pgsql-hackers по дате отправления: