Re: pg_sequence catalog
От | Peter Eisentraut |
---|---|
Тема | Re: pg_sequence catalog |
Дата | |
Msg-id | bbb84c37-9a7c-ae51-c143-7b3fb3a6f235@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: pg_sequence catalog (Andreas Karlsson <andreas@proxel.se>) |
Ответы |
Re: pg_sequence catalog
|
Список | pgsql-hackers |
On 11/11/16 10:06 PM, Andreas Karlsson wrote: > As pointed out by Peter this patch also requires the changes to > pg_upgrade. I have not looked at those patches. The required changes to pg_upgrade have been committed, so that will work now. > - The pg_dump tests fails due to the pg_dump code not being updated. I > have attached a patch which fixes this. fixed > 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. I have done a fair amount of performance testing and the results were usually in the neighborhood of 1%-2% slower or faster, nothing really clear. But running nextval by itself in a tight loop isn't really a normal use. The important thing is the concurrency behavior. > > @@ -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". The sequence tuple has to be deleted in addition to the heap drop. I have added a comment to make the clearer. > The patch does not update catalogs.sgml which it should do. added -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: