-
Suggestion
-
Resolution: Fixed
-
None
-
106
-
49
-
-
Problem
Some JIRA tables, like the propertyentry table contains many single column indexes, but many of the of SQL queries run by JIRA actually include checks for 2 or 3 of the columns.
For example:
propertyentry has indices on:
jira728=# \d propertyentry ; Table "public.propertyentry" Column | Type | Modifiers --------------+------------------------+----------- id | numeric(18,0) | not null entity_name | character varying(255) | entity_id | numeric(18,0) | property_key | character varying(255) | propertytype | numeric(9,0) | Indexes: "pk_propertyentry" PRIMARY KEY, btree (id) "osproperty_all" btree (entity_id) "osproperty_entityname" btree (entity_name) "osproperty_propertykey" btree (property_key)
A majority of the SQL queries run against this table include:
- ENTITY_NAME, ENTITY_ID,PROPERTY_KEY
SELECT ID, propertytype FROM propertyentry WHERE ENTITY_NAME= @P0 AND ENTITY_ID= @P1 AND PROPERTY_KEY= @P2
- entity_name,entity_id
select O_S_PROPERTY_ENTRY.property_key, O_S_PROPERTY_ENTRY.propertytype from propertyentry O_S_PROPERTY_ENTRY where O_S_PROPERTY_ENTRY.entity_name = :1 and O_S_PROPERTY_ENTRY.entity_id = :2 order by O_S_PROPERTY_ENTRY.id desc
In these cases, it is left to the database to try and determine which index should be used, which is not always efficient. It may even cause extremely slow query times.
Suggestion
Add multi-column index to the table.
- Suggested index for Oracle:
CREATE INDEX PROPERTYENTRY_ENTITY_ID_NAME ON PROPERTYENTRY (ENTITY_ID, ENTITY_NAME) TABLESPACE JIRA;
- Suggested index for PostgreSQL:
CREATE INDEX propertyentry_idx_entity_id_entity_name ON public.propertyentry USING btree (entity_id, entity_name COLLATE pg_catalog."default");
- Suggested index for MSSQL:
CREATE NONCLUSTERED INDEX PROPERTYENTRY_IDX_ENTITY_ID_PROPERTY ON PROPERTYENTRY(ENTITY_ID,PROPERTY_KEY) INCLUDE(ENTITY_NAME)
- is duplicated by
-
JRASERVER-38825 Improve Database Indexes to the PROPERTYENTRY Table
- Closed
- relates to
-
JRASERVER-71350 Batching notifications tables can lead to high CPU usage on MSSQL and cause Batched Notifications to be sent with a long delay
-
- In Progress
-
-
JRASERVER-67333 Performance degradation due to a high number of requests to the table propertyentry
-
- Closed
-
-
JRASERVER-63002 Create new composite indexes for changegroup and changeitem tables to improve performance
-
- Closed
-
-
JRASERVER-65845 Possible deadlock in MS SQL and MySQL on CachingOfBizPropertyEntryStore
-
- Closed
-
-
JRASERVER-38825 Improve Database Indexes to the PROPERTYENTRY Table
- Closed
- Mentioned in
- mentioned in
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
Hi everyone,
Just a quick follow-up about the changes related to this issue that are coming down the pipeline with 8.0.
Unfortunately, due to ZDU compatibility concerns, we are not targeting the 7.x series for this fix. That said, these changes can be performed manually by a dba on the 7.x side.
So what's changing with 8.0? First, we're adding a new index on entity_id, entity_name, and property_key (except SqlServer, see details below). And second, we're dropping two of the table's existing indexes: os_property_all and entity_name.
Beyond that, there's one added wrinkle worth mentioning: as the original issue description notes, for SqlServer 2014 and earlier, all three of the key-columns will not fit within the index-key. There's a size limit that would be violated. Thus, for this special case, we create an index-key on entity_id and entity_name and then add property_key as an included column.
Thanks for again your patience!
Seth