Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
A complete cloud platform for an app or your entire digital business
Detect and predict anomalies by automating machine learning to achieve higher asset uptime and maximized yield
Automate decision processes with a no-code business rules engine
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Personalize and optimize the customer experience across digital touchpoints
Build, protect and deploy apps across any platform and mobile device
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Quick question, I was just wondering and I couldn't find the information, would it be costly in time to add a new indexed field to a large table (let's assume in range of several millions records)?
That would be for a non enterprise version of the database.
You can add new index as inactive and run idxactivate later. A few millions records is not a large table. If a downtime is exceptable then you can use idxbuild instead of idxactivate. But adding an active index (offline or online) is a bad idea.
Thanks for your answer, I was thinking of creating the index inactive and enable it later, by idxactive or idxbuild, but it is more out of curiosity, if it is a new field, hence with all records with same value, should it be a quick process to activate the index or would it be a long(ish) process?
If you add an active index or use the idxactive then Progress will use an algorithm where each index key will be inserted into an existent index tree. With non-unique values in the indexed fields the tree will be compact but the process will still create one bi note per each key insertion. The whole process will not be much faster.