InterSystems Ideas

Have an idea, suggestion, or something that doesn’t work as expected in InterSystems products or services? Share it here on the InterSystems Ideas Portal.

The Ideas Portal is where community members can propose improvements, report bugs, and help influence the product roadmap across InterSystems products and the overall developer experience. 22% of submitted ideas are implemented by InterSystems or members of the Developer Community.

💡 Ideas and bugs are both welcome, no matter how big or small. You can submit feature requests, usability improvements, workflow suggestions, and bug reports. Whether you’re an experienced expert or just getting started, your fresh perspective is valuable.

🛠️ About bugs and fixes. If you have access to InterSystems WRC, please submit bugs there for immediate action. Bug reports submitted through the Ideas Portal are reviewed and tracked, but do not guarantee immediate resolution.

Start by sharing what could be better - the community and our teams will help take it from there.

Add a new idea Subscribe
Status Will not implement
Categories InterSystems IRIS
Created by Nelson Tarr
Created on Aug 2, 2023

RELATED IDEAS

Why use storage for an index that has never been used?

If an index has never been used (or not for a long time), is it really necessary to use hard drive storage for the index?

After a sufficiently long time has passed, it seems like it would be possible to purge storage of index data. The index would need to be rebuilt if the index becomes required for a query.

Alternatively, a different implementation approach could be taken. It seems possible for indices to start off disabled. Once an index is used (for a query), it would become enabled automatically and rebuilt from existing table data.

The benefit of this approach would be somewhat reduced storage footprint. Secondary benefits may includes slightly faster save operations, and (possibly) slightly reduced journal footprint.

This approach would effectively catch cases where indices exist in class definitions but are no longer relevant for queries. It would also catch cases where data is persisted, but queries are never run against the class at all.

  • ADMIN RESPONSE
    Oct 28, 2024

    Thank you for submitting the idea. Based on information from our experts the status of your idea was changed to "Will not implement". Please look for details in the comments on the idea. Good luck!

  • Post comment
  • Benjamin De Boe
    Oct 28, 2024

    We do not expect to be adding this to our platform roadmap in the foreseeable future, hence marking as "Will not implement"

    Reply
  • Benjamin De Boe
    Jan 2, 2024

    Hi Nelson,

    [apologies for the late response. only got wind of this one last week]

    we intend to look into more automation around index analysis in the new calendar year, but because indices are table properties and not runtime aspects, the on-demand thing you're suggesting would require quite fundamental changes to our model. I'd also like to differentiate between system classes that are part of the core system (in IRISLIB) and those at the application layer (where I would categorize HSLIB), as the application has much more knowledge about expected usage patterns to anticipate which indices need to be considered. If you have specific thoughts about yours, please get in touch directly.

    Thanks,
    benjamin

    Reply
  • Admin
    Vadim Aniskin
    Aug 16, 2023

    Hi Nelson! Thank you for clarifying! Your idea has been promoted to the "Idea-A-Thon" status again.

    Reply
  • Nelson Tarr
    Aug 16, 2023

    Vadim and Alexander, thanks for the helpful information. Yes I believe my suggestion is similar to running the Index Usage report and looking for indices that are never used. However, I want to include all classes (including system classes). I believe the main difference in my suggestion is that I'm suggesting an automated or at least simplified approach to this. Furthermore, if there are unused indices in System tables, then I don't believe those could or should be modified by our users.

    I am also suggesting the possibility that indices might default to this "transient" behavior until they are used the first time. For example, let's suppose I'm a user who never makes use of Embedded Python functionality. As a hypothetical (an probably inaccurate) example, let's also suppose that Embedded Python uses queries and indices against the System CompiledClass table. If I never use Embedded Python and never use these queries, I might be better off not storing the related indices. It seems to me that we currently store all indices just in case they might be used, rather than wait and enable them "on-demand". I realize this would impose a performance penalty the first time, but in some cases this might be an overall improvement.

    Happy to take additional questions offline too

    Reply
  • Admin
    Vadim Aniskin
    Aug 16, 2023

    Hi Nelson!

    Is your idea similar to existing IRIS functionality mentioned in the comment from Alexander Koblov? If not, please explain the difference.

    Reply
  • Alexander Koblov
    Aug 16, 2023

    Nelson, there is already Index Analyzer in IRIS. You can use it to find indices that are used and not used

    https://docs.intersystems.com/iris20232/csp/docbook/DocBook.UI.Page.cls?KEY=GSOD_indexes#GSOD_indexes_analyze

    Rebuilding index might take a long time. And the bigger the index, the longer it might take

    Reply