Non-transactional pg_class, try 2
От | Alvaro Herrera |
---|---|
Тема | Non-transactional pg_class, try 2 |
Дата | |
Msg-id | 20060611215318.GA15181@alvh.no-ip.org обсуждение исходный текст |
Ответы |
Re: Non-transactional pg_class, try 2
The corresponding relminxid patch; try 1 Re: Non-transactional pg_class, try 2 Re: Non-transactional pg_class, try 2 |
Список | pgsql-patches |
Here I repost the patch to implement non-transactional catalogs, the first of which is pg_ntclass, intended to hold the non-transactional info about pg_class (reltuples, relpages). pg_ntclass is a relation of a new relkind, RELKIND_NON_TRANSACTIONAL (ideas for shorter names welcome). In pg_class, we store a TID to the corresponding tuple. The tuples are not cached; they are obtained by heap_fetch() each time they are requested. This may be worth reconsideration. heap_update refuses to operate on a non-transactional catalog, because there's no (easy) way to update pg_class accordingly. This normally shouldn't be a problem. vac_update_relstats updates the tuple by using the new heap_inplace_update call. VACUUM FULL also refuses to operate on these tables, and ANALYZE silently skips them. Only plain VACUUM cleans them. Note that you can DELETE from pg_ntclass. Not sure if we should disallow it somehow, because it's not easy to get out from that if you do. (But it's possible -- just insert enough tuples until you reach the needed TID, and then delete the ones that are not pointed by any pg_class row). Regression test pass; I updated the stats test because it was accessing pg_class.relpages. So there's already a test to verify that it's working. There is one caveat that I'm worried about. I had to add a "typedef" to pg_class.h to put ItemPointerData in FormData_pg_class, because the C struct doesn't recognize the "tid" type, but the bootstrap type system does not recognize ItemPointerData as a valid type. I find this mighty ugly because it will have side effects whenever we #include pg_class.h (which is virtually anywhere, since that header is #included in htup.h which in turn is included almost everywhere). Suggestions welcome. Maybe this is not a problem. Other two caveats are: 1. During bootstrap, RelationBuildLocalRelation creates nailed relations with hardcoded TID=(0,1). This is because we don't have access to pg_class yet, so we can't find the real pointer; and furthermore, we are going to fix the entries later in the bootstrapping process. 2. The whole VACUUM/VACUUM FULL/ANALYZE relation list stuff is pretty ugly as well; and autovacuum is skipping pg_ntclass (really all non-transactional catalogs) altogether. We could improve the situation by introducing some sort of struct like {relid, relkind}, so that vacuum_rel could know what relkind to expect, and it could skip non-transactional catalogs cleanly in vacuum full and analyze. I intend to apply this patch by tuesday or wednesday, unless an objection is raised prior to that.
Вложения
В списке pgsql-patches по дате отправления: