Gilad Chaplik has posted comments on this change. Change subject: db: Numa support database implementation ......................................................................
Patch Set 15: (6 comments) http://gerrit.ovirt.org/#/c/26996/15/packaging/dbscripts/upgrade/03_05_0330_add_numa_tables_and_columns.sql File packaging/dbscripts/upgrade/03_05_0330_add_numa_tables_and_columns.sql: Line 5: -- Numa nodes table Line 6: CREATE TABLE numa_node Line 7: ( Line 8: numa_node_id UUID NOT NULL, Line 9: vm_or_vds_guid UUID NOT NULL, > 2 columns. you need to have FK with delete cascade for this field. maybe this can help: http://stackoverflow.com/questions/10068033/postgresql-foreign-key-referencing-primary-keys-of-two-different-tables Line 10: numa_node_index INTEGER, Line 11: mem_total BIGINT, Line 12: cpu_count INTEGER, Line 13: mem_free BIGINT, Line 45: id UUID NOT NULL, Line 46: vm_numa_node_id UUID NOT NULL, Line 47: vds_numa_node_id UUID NOT NULL, Line 48: CONSTRAINT pk_vm_vds_numa_node_map PRIMARY KEY(id), Line 49: CONSTRAINT fk_vm_vds_numa_node_map_vds_numa_node FOREIGN KEY(vds_numa_node_id) REFERENCES numa_node(numa_node_id) ON DELETE CASCADE, > Please elaborate what do you mean vm node can be pinned without any pnode. incase you delete a host the pNodes are deleted. but vNode can still be pinned. Line 50: CONSTRAINT fk_vm_vds_numa_node_map_vm_numa_node FOREIGN KEY(vm_numa_node_id) REFERENCES numa_node(numa_node_id) ON DELETE CASCADE Line 51: ); Line 52: Line 53: -- Create partial index for numa node map Line 47: vds_numa_node_id UUID NOT NULL, Line 48: CONSTRAINT pk_vm_vds_numa_node_map PRIMARY KEY(id), Line 49: CONSTRAINT fk_vm_vds_numa_node_map_vds_numa_node FOREIGN KEY(vds_numa_node_id) REFERENCES numa_node(numa_node_id) ON DELETE CASCADE, Line 50: CONSTRAINT fk_vm_vds_numa_node_map_vm_numa_node FOREIGN KEY(vm_numa_node_id) REFERENCES numa_node(numa_node_id) ON DELETE CASCADE Line 51: ); > Will add this later. why not now? Line 52: Line 53: -- Create partial index for numa node map Line 54: CREATE INDEX IDX_vm_vds_numa_node_map_vm_numa_node_id ON vm_vds_numa_node_map(vm_numa_node_id); Line 55: CREATE INDEX IDX_vm_vds_numa_node_map_vds_numa_node_id ON vm_vds_numa_node_map(vds_numa_node_id); Line 61: numa_node_id UUID NOT NULL, Line 62: cpu_core_id INTEGER, Line 63: CONSTRAINT pk_numa_node_cpu_map PRIMARY KEY(id), Line 64: CONSTRAINT fk_numa_node_cpu_map_numa_node FOREIGN KEY(numa_node_id) REFERENCES numa_node(numa_node_id) ON DELETE CASCADE Line 65: ); > This table only store the cpu id(0,1,2...) of each node, not the pk of cpu okay for now. Line 66: Line 67: -- Create partial index for numa node cpu map Line 68: CREATE INDEX IDX_numa_node_cpu_map_numa_node_id ON numa_node_cpu_map(numa_node_id); Line 69: Line 75: to_numa_node_index INTEGER, Line 76: distance INTEGER, Line 77: CONSTRAINT pk_numa_node_distance PRIMARY KEY(id), Line 78: CONSTRAINT fk_numa_node_distance_numa_node FOREIGN KEY(numa_node_id) REFERENCES numa_node(numa_node_id) ON DELETE CASCADE Line 79: ); > If use one field, it can't support query in future. Do you think so? you are right, but don't think it's needed in db level. cpu mapping (comment above) is more appropriate for table and you didn't go for it. Line 80: Line 81: -- Create partial index for numa node distance Line 82: CREATE INDEX IDX_numa_node_distance_numa_node_id ON numa_node_distance(numa_node_id); Line 83: Line 98: Line 99: -- Add columns in table vds_dynamic Line 100: PERFORM fn_db_add_column('vds_dynamic', 'auto_numa_balancing', 'integer'); Line 101: PERFORM fn_db_add_column('vds_dynamic', 'vds_numa_node_count', 'integer'); Line 102: > in db, we can judge this through vds_numa_node_count(only one numa node mea why we need to know the count at VDS level? Line 103: END; $procedure$ Line 104: LANGUAGE plpgsql; Line 105: Line 106: select __temp_add_numa_columns(); -- To view, visit http://gerrit.ovirt.org/26996 To unsubscribe, visit http://gerrit.ovirt.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I2507c084aa214bcfb65e860b11ed7dcf02af50cc Gerrit-PatchSet: 15 Gerrit-Project: ovirt-engine Gerrit-Branch: master Gerrit-Owner: Xiaolei Shi <xiao-lei....@hp.com> Gerrit-Reviewer: Doron Fediuck <dfedi...@redhat.com> Gerrit-Reviewer: Eli Mesika <emes...@redhat.com> Gerrit-Reviewer: Gilad Chaplik <gchap...@redhat.com> Gerrit-Reviewer: Jason Liao <chuan.l...@hp.com> Gerrit-Reviewer: Martin Sivák <msi...@redhat.com> Gerrit-Reviewer: Xiaolei Shi <xiao-lei....@hp.com> Gerrit-Reviewer: automat...@ovirt.org Gerrit-Reviewer: oVirt Jenkins CI Server Gerrit-HasComments: Yes _______________________________________________ Engine-patches mailing list Engine-patches@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-patches
