Re: pg_sequence catalog
От | Andreas Karlsson |
---|---|
Тема | Re: pg_sequence catalog |
Дата | |
Msg-id | b330f4c4-6bc2-0a25-be6b-14f85c347361@proxel.se обсуждение исходный текст |
Ответ на | Re: pg_sequence catalog (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: pg_sequence catalog
|
Список | pgsql-hackers |
Review for pg_sequence catalog I like this change since it moves all the parts which should be transactional to the system catalogs while keeping the only non-transactional stuff in the sequence relations. There was some discussion upthread about more compact representations for the sequences, but I feel that is a separate issue mostly unrelated to this patch. I might play around more with it but it seems to work well so far. As pointed out by Peter this patch also requires the changes to pg_upgrade. I have not looked at those patches. = Functional review - The patch applies and compiles and seems to work fine after some quick manual testing. - The pg_dump tests fails due to the pg_dump code not being updated. I have attached a patch which fixes this. = Benchmarks I was a bit worried that the extra syscache lookups might slow down nextval(), but I got a measurable speed up on a very simple workload which consisted of only calls to nextval() to one sequence. The speedup was about 10% on my machine. = Code The changes to the code looks generally good. > @@ -1155,6 +1156,8 @@ doDeletion(const ObjectAddress *object, int flags) > else > heap_drop_with_catalog(object->objectId); > } > + if (relKind == RELKIND_SEQUENCE) > + DeleteSequenceTuple(object->objectId); > break; > } I think it might be cleaner here to put this as a "else if" just like "relKind == RELKIND_INDEX". = Documentation The patch does not update catalogs.sgml which it should do. Andreas
Вложения
В списке pgsql-hackers по дате отправления: