|From:||Andreas Karlsson <andreas(at)proxel(dot)se>|
|To:||Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: pg_sequence catalog|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
- The pg_dump tests fails due to the pg_dump code not being updated. I
have attached a patch which fixes this.
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.
The changes to the code looks generally good.
> @@ -1155,6 +1156,8 @@ doDeletion(const ObjectAddress *object, int flags)
> + if (relKind == RELKIND_SEQUENCE)
> + DeleteSequenceTuple(object->objectId);
I think it might be cleaner here to put this as a "else if" just like
"relKind == RELKIND_INDEX".
The patch does not update catalogs.sgml which it should do.
|Next Message||Craig Ringer||2016-11-12 03:27:46||Re: Why PostgreSQL doesn't implement a semi sync replication?|
|Previous Message||Amit Kapila||2016-11-12 03:03:33||Re: Remove the comment on the countereffectiveness of large shared_buffers on Windows|