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

Provide ability to log via TRACE usage of preliminarily selected indexes in queries [CORE4183] #4509

Open
firebird-automations opened this issue Aug 19, 2013 · 2 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @pavel-zotov

Currently we can not be sure whether some index (say, MY_INDEX_A) is ever in use or not.
All indexes decrease performance (more or less) of inserts and updates and also they all will be handled by GC that can take significant time.
So the rule of thumb is simple: do not create index "just in case". But in real prod systems this rule often is violated and one can hard to find where some index 'X' is used.

It will be useful if trace config will contain something like 'INDEX_FILTER <my_index_name1 | my_index_name2 | %my_pattern%>' for such logging.

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

Why did you add the word "preliminary" to the case description?

In what context do you mean "preliminary"?

@firebird-automations
Copy link
Collaborator Author

Commented by: @pavel-zotov

When there is a doubt about whether some index is ever selected by FB optimizer or not - it will be good idea to add it's name to trace config list of arguments for special (new) parameter.

PS. Sorry, my english is bad. If this word - 'preliminary' - isn`t properly used please remove it from the header of ticked.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant