Background: Table has about 200m rows 55GB.
I need to do a row copy-over to a duplicate table but with a BIGINT identity and of course when generating the script to CREATE from original table it leaves everything the same, including the table name, INT value of the PK, and the PRIMARY KEY CONSTRAINT – all of which need to be changed.
My question is, if I change the PRIMARY KEY CONSTRAINT name, and don’t change it back, will it screw things up? Might stored procedures or direct commands call this constraint directly, as an index or something? If it needs to be renamed later, is that an instantaneous process or a long one being such a large table?
I don’t think it matters about the other indexes because I should just drop them on the original table before recreating on the new one, right?
And one more question: On a table this size – and a high volume system, with performance in mind, should I be reconsidering changing any of the following values?:
WITH (
PAD_INDEX = OFF,
STATISTICS_NORECOMPUTE = OFF,
IGNORE_DUP_KEY = OFF,
ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON,
FILLFACTOR = 95
) ON [PRIMARY]
Index names are usually not directly referenced in programming API. There is no ‘select from index’ nor ‘insert into index’ syntax, everything references the table object. In few places though the index name is exposed, like for instance table hints.
But you may have in place administrative/maintenance scripts/jobs that are aware of the physical layout (ie. index and constraint names).