Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DB performance: indexing #488

Closed
3 tasks done
Michiel-s opened this issue Jul 25, 2016 · 3 comments
Closed
3 tasks done

DB performance: indexing #488

Michiel-s opened this issue Jul 25, 2016 · 3 comments
Assignees
Labels
bug Indicates an unexpected problem or unintended behavior

Comments

@Michiel-s
Copy link
Member

Michiel-s commented Jul 25, 2016

In order to increase the database performance, commit e715f52 introduced indexes on table columns where possible.

We argued that the performance improvements of indexes for Ampersand generally outweigh the costs for updating the index on inserts, updates and deletes. Therefore this feature is enabled by default. You can manually remove indexes when necessary.

TODO:

  • For n-n tables, the index is still missing on the first column.
  • For single column concept tables there is no primary key defined. Adding the PK will guarantee that there are no duplicates in the table.
  • For n-n tables we can also defined a primary key statement on the combination of both columns. This will guarantee that there are no duplicates in the table.
@Michiel-s Michiel-s added the bug Indicates an unexpected problem or unintended behavior label Jul 25, 2016
hanjoosten added a commit that referenced this issue Jul 25, 2016
@Michiel-s
Copy link
Member Author

Minor fix: a1d7f67

@Michiel-s
Copy link
Member Author

I've updated the initial post and added two todo's

Michiel-s pushed a commit that referenced this issue Jul 26, 2016
Issues not yet fully fixed, but merged for now.

Commits:
* this should fix issue #486 
* Fix issue #488
* Minor code cleanup
* Releasenotes
* fix bug. The default was not as I expected.
* Bugfix e5386cf
* Revert "fix bug. The default was not as I expected."
@hanjoosten hanjoosten reopened this Aug 8, 2016
@hanjoosten
Copy link
Member

@stefjoosten found a bug as a result of putting a primary key on the n-n table: In case that one of the columns has a technical type that is not suitable as primary key, there must not be a primary key defined on that table.

hanjoosten added a commit that referenced this issue Aug 8, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Indicates an unexpected problem or unintended behavior
Projects
None yet
Development

No branches or pull requests

2 participants