Hi, 

We're aware of that issue and are working to solve it. In the next release of Commerce, the version sync issue should be gone and the performance gain should be very significant. 

Stay tuned.

Regards.

/Q

Sounds good! Is there any bug or story connected to this, so we can track the proceedings? When is next release planned?

I don't think we have public stories - so you might not have access to that. I can't say for sure about the timeframe, but it should be no later than this fall.

Regards.

/Q

Thank you very much for your fast responses. Is there anything we can do in the meantime? Applying index to that column for BigTable did not work after site restart. We enabled the "DisableVersionSync", but just to make sure, this is not completely removing the sync jobs?

Enabling DisableVersionSync will skip the version sync if you're using other APIs then Content API. For example, if you use ICatalogSystem to save CatalogEntryDto or when you import the catalog. When you use Content API, there still be some slowness due to DDS.

Regards.

/Q

How did you import products from other system? Did you use Content API or using catalog import export? If you are using Content API then you might want to save the content with the extended flag ExtendedSaveAction.ClearVersions.

In the meantime, since you don't want catalog version at all, you can clean up the big table by executing these: DELETE FROM [tblBigTable] WHERE StoreName='EPiServer.Commerce.Catalog.Provider.CatalogContentDraft' and DELETE FROM tblBigTableReference WHERE PropertyName='ContentReferenceToSoftlinkMapping'. As always, please backup your database first.

I will answer instead of Rasmus. We are importing products using via ICatalogSystem (e.g. ICatalogSystem.SaveCatalogEntry(catalogEntryDto)). Is it safe for us to do clean up of big tables since we don't care about products/nodes versions because all changes comes from external system. It shouldn't affect page versions in CMS or anything else, right?

Any other ideas are appreciated too. Thank you.

Yes, it would be safe for having no catalog version at all.

EDIT: I want to note that tblBigtable is home of other data also, so be careful with the store you work with (CatalogContentDraftStore)

Regards.

/Q

We have tried to add the corresponding index the SQL performance monitor suggest:

/*
Missing Index Details from ExecutionPlan1.sqlplan
The Query Processor estimates that implementing the following index could improve the query cost by 94.7742%.
*/

/*
GO
CREATE NONCLUSTERED INDEX [<Name of Missing Index, sysname,>]
ON [dbo].[tblBigTable] ([Row])
INCLUDE ([pkId],[String01])
GO
*/

This will cause this error. Can we solve that following problem somehow? After removing the index again the application starts without problems.